Any technical reason not to use Call in VB6?

[OldClock]

Hey

If you know of any technical reasons why one should not call functions using "Call" in VB6 other than because its deprecated, I'd like to hear them.

[Krool]

It's not needed. (Technically)

I have the habbit to use 'Call' when calling an own custom Sub method. Else when calling an function or API I use without 'Call'.
But that's just a personal habbit and no technically need.
I think it is some very old Basic keyword that is supported to mantain compatibility..

[The trick]

http://bbs.vbstreets.ru/viewtopic.php?f=68&t=43984

Public Sub Name()
    MsgBox "I'm Name subroutine"
End Sub

Private Sub Main()
    On Error Resume Next
    Call Name
    Name "c:\pagefile.sys" As "c:\swapfile.sys"
End Sub

Try to remove Call.

[OldClock]

Good example. To me, that's more of a reason not to use reserved words in VB6 than a reason for using "Call" - not only because using reserved words could make reading code confusing, but also because chaos will ensue regarding capitalization in your diffs. For example, let's say you use a variable called "index" (lowercase), or "x" (lowercase), then add a sub for a _MouseMove event... VB will change the case of some (not necessarily all) instances of your variables in completely unrelated routines just because you added the _MouseMove sub, leading to a complete mess in the diff and trouble merging with other team members.

[Shaggy Hiker]

Thread moved from CodeBank, which is for finished code snippets rather than questions.

[couttsj]

I personally use "Call" a lot. Most sub routines I write as functions returning a Boolean True or False. Using the "Call" word allows me to ignore that value. If I want to verify success of the routine, I can check the return value. It gives me more options.

J.A. Coutts

[dilettante]

You don't need to use the archaic Call statement to invoke a Function.

[vb6forever]

My personal preference has always been to use call.
I find it helps to quickly ID a procedure when reviewing code,
and hence give me a mental roadmap of where I'm at.

[Phill.W]

"Call" is no more deprecated than any other bit of VB "Proper".

Personally, I use Call because I also work with other languages where the the use of brackets is required.
It makes shifting from one language to another [slightly] less jarring.

Regards, Phill W.

[RobDog888]

Call has been considered "bad" to use not from a technical standpoint but rather from a good coding standard/syntax. I haven't used it since the days of BASIC.

[DEXWERX]

"Call" is no more deprecated than any other bit of VB "Proper".

Personally, I use Call because I also work with other languages where the the use of brackets is required.
It makes shifting from one language to another [slightly] less jarring.

Regards, Phill W.

That's why I used to use it.

[baka]

is there any difference in the compiled executable when using "call" to call a function?

[techgnome]

There's no technical reason to not use it just as there's no technical reason to use it. It's purely aesthetic and personal. I personally find it superfluous and unnecessary. To me, it just creates noise that I find distracting. Of course I'm calling something. VB is already verbose enough on it's own, I don't need to be adding optional keywords to my code.

That said, I may find it irritating, noisy, and I may mention something to the coder, but that's as far as it's going to go. I'm not going to champion that they take them out, or hold it against them.

-tg

[Phill.W]

None at all.

Regards, Phill W.

[Elroy]

To my eyes, this is just one of those "personal style" issues, that each programmer needs to decide for themselves. We may get dogmatic, defending our personal style, but, IMHO, that's just silliness.

It's similar to...

• whether or not to indent the "Case" statements in a "Select Case" block.
• whether it's essential that all constants be capitalized.
• whether procedure comments should be place before or after the first procedure definition line.
• whether we should prefix all control names with txt, cbo, lbl, etc.
• whether we should use "Dim" vs "Private" with module level variable declarations.
• whether or not we should be allowed to put two (or three, or more) statements on a single line with the colon.
• etcetera etcetera.

Certainly, there are some things that actually make a difference, but I don't think any of the ones I've listed make one iota of difference, except for the visual appearance of the source code.

It's just a matter of style, and we'll always each have our own. And, a bit of flexibility in this regard may not be all bad.

Best Regards,
Elroy

EDIT1: Just to say it before someone else does, yeah, a single-line "If" statement will compile a bit differently than a multi-line "If". But that's not exactly what I meant.

[LaVolpe]

Agreed... a personal choice. My preference is to use it for subroutines that have no parameters or a function with no parameters and I don't care about the return value. I typically don't like to see a single function/sub name on a line all by itself; it almost feels like some orphaned statement/code.

For example: let's pretend we have a private subroutine called Cleanup
Instead of: Cleanup
I would typically use: Call Cleanup

[Eduardo-]

Occam's razor

[The trick]

Private Sub Form_Load()
    Dim l1 As Long, l2 As Long
    
    Foo (l1)
    Call Foo(l2)
    
    Debug.Print l1, l2
    
End Sub

Private Sub Foo( _
            ByRef l As Long)
    l = 100
End Sub

[LaVolpe]

The trick: Call Foo((l2)) is same effect as Foo (l1).

Not sure what you were trying to say with your sample code. I think most of us know the effect of enclosing byref parameters with parentheses?

[DEXWERX]

The trick: Call Foo((l2)) is same effect as Foo (l1).

Not sure what you were trying to say with your sample code. I think most of us know the effect of enclosing byref parameters with parentheses?

i think his point is that most of us actually don't
and by "us" i mean the vast majority of the VB community, not us in this thread.

I don't know any other language with a similar construct of creating a temp variable using parenthesis.

[The trick]

I wanted to show if we just remove call keyword in some cases it'll actually compile but it gives other result. Of course we know about parentheses but in such cases it can produce unexpected behavior. Sorry if I offended someone.

[DataMiser]

I do not use the call keyword, haven't for many years. Can't even remember now where it was last required, VBDos maybe or maybe even before that. I know it has been at least 20 years since I felt the need to use it in any code and always cringe a little when I see someone else use it. Always expect to see them using the Let keyword as well

[Bobbles]

I believe it makes the code more readable/understandable

[dreammanor]

IMO, Call has the following functions
(1) no return value
(2) different from other lines of source code
(3) play a role of emphasis
(4) to make the source code a little more clear
(5) and the meaning of nostalgia
(6) to make the programming style diversified (this is a good thing and also a bad thing)
(7) keep spaces on the left of a source code line

Sub Test()

Method1: Method2 '// There is no space to the left of the code line

**** Call Method1:    Method2 '// There is 4 spaces to the left of the code line

End Sub

However, I only use Call occasionally.

[dreammanor]

sorry, deleted the duplicate post.

[dz32]

[...]

[HuffAZ]

It's a personal choice with no right or wrong. I use Call only for better readability in my opinion. Calls to subroutines vs functions vs variable names stand out better. Yes, I know you can easily tell anyways but Call for me adds readability rather than degrades from it. Especially when explaining code snippets to non-programmers such as mechanical engineers.

An old keyword that I doubt anyone still uses would be LET

[Elroy]

Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)

However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.

But, here comes the catch. When I'm writing code, I may not have it entirely debugged on the first pass. For instance, I may try to set image attributes before I've created a hImgAttr handle. So, if I'm not checking for errors, how do I track this down?

Simple, I use "Call" for all my API calls into the GDI+. And, when something has gone awry, I replace all these "Call" statements with a "MsgBox" statement. This allows me to basically step-through the code (with message boxes), and figure out what I've done wrong. And, if I hadn't used the "Call" convention, it'd be much harder to do this.

Also, at some point, I might replace the "Call" statements with "Gdip_CheckForErrors" procedures. It's just a thought, a universal GDI+ error checker procedure.

Just Saying,
Elroy

[DEXWERX]

that's how the C++ class wrappers work. they save the last error code using SetStatus().

Graphics.cls

Public Function DrawLineI(Pen As Pen, ByVal X1 As Long, ByVal Y1 As Long, ByVal X2 As Long, ByVal Y2 As Long) As GpStatus
    DrawLineI = SetStatus(DLLExports.GdipDrawLineI(m_nativeGraphics, Pen.NativePen, X1, Y1, X2, Y2))
End Function

[dreammanor]

Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)

However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.

But, here comes the catch. When I'm writing code, I may not have it entirely debugged on the first pass. For instance, I may try to set image attributes before I've created a hImgAttr handle. So, if I'm not checking for errors, how do I track this down?

Simple, I use "Call" for all my API calls into the GDI+. And, when something has gone awry, I replace all these "Call" statements with a "MsgBox" statement. This allows me to basically step-through the code (with message boxes), and figure out what I've done wrong. And, if I hadn't used the "Call" convention, it'd be much harder to do this.

Also, at some point, I might replace the "Call" statements with "Gdip_CheckForErrors" procedures. It's just a thought, a universal GDI+ error checker procedure.

Just Saying,
Elroy

Golang allows functions to return multiple values. That feature is useful.

[couttsj]

Well, I ran across a good reason to use "Call" (and I was in the habit of not using it). If you're following threads, you'll know I've been dabbling in the GDI+. Almost all of these GDI+ APIs are "Functions". And, as such, they return either zero, or an error code. (Any returned pointers, etcetera, are returned in passed arguments and not as the function's return value.)
Elroy

Pretty much what I said back in post 6, although I didn't explain it in as much depth.

J.A. Coutts

[dilettante]

However, I'm not one to go overboard on checking to make sure every step worked without error. To me, it just seems like WAY overkill. I mean, if the GDI+ initialized, why wouldn't it create a new image with a call to GdipCreateBitmapFromScan0? It just seems to clutter up code worrying about every possible error.

This extra effort is why we have the HRESULT-driven exception mechanism for COM member calls: it makes for more compact coding and less disruption of logical flow in your source code. Of course that's only viable if you do proper exception handling and take appropriate actions unless you are willing to have exceptions terminate your program.

What errors?

Private Enum GpStatus
    Ok = 0
    GenericError = 1
    InvalidParameter = 2
    OutOfMemory = 3
    ObjectBusy = 4
    InsufficientBuffer = 5
    NotImplemented = 6
    Win32Error = 7
    WrongState = 8
    Aborted = 9
    FileNotFound = 10
    ValueOverflow = 11
    AccessDenied = 12
    UnknownImageFormat = 13
    FontFamilyNotFound = 14
    FontStyleNotFound = 15
    NotTrueTypeFont = 16
    UnsupportedGdiplusVersion = 17
    GdiplusNotInitialized = 18
    PropertyNotFound = 19
    PropertyNotSupported = 20
End Enum

What you suggest is the same as putting On Error Resume Next at the head of every procedure. Not a good idea ever, and in this case you risk GDI+ and GDI object leaks, memory leaks of other kinds, data corruption, etc.


I fail to see how any of that relates to use of the obsolete and eye-jarring Call statement left over from ancient Microsoft Basic dialects. If you want to ignore the returned result then you can use the proper subroutine call syntax that was added long ago to treat subroutines as verbs. I don't expect anyone to change his mind based on my recommendation though.

[Elroy]

I don't expect anyone to change his mind based on my recommendation though.

----

[RobDog888]

Using Call is just uncalled for

[Elroy]

Ok ok ok.

I built this little function that I now use. I replaced all my "Call" statements with that little "Retn" procedure, all all for dilettante.

Private Sub Retn(GdipReturn As Long)
    ' Just to check for any errors.
    '
    If GdipReturn = Ok Then Exit Sub
    If Not InIde6 Then Exit Sub
                                        Debug.Print "GDI+ Error:  ";
    Select Case GdipReturn
    Case GenericError:                  Debug.Print "Generic Error"
    Case InvalidParameter:              Debug.Print "Invalid Parameter/Argument"
    Case OutOfMemory:                   Debug.Print "Out Of Memory"
    Case ObjectBusy:                    Debug.Print "Object Busy, already in use in another thread"
    Case InsufficientBuffer:            Debug.Print "Insufficient Buffer, buffer specified as an argument in the API call is not large enough"
    Case NotImplemented:                Debug.Print "Method Not Implemented"
    Case Win32Error:                    Debug.Print "Win32 Error"
    Case WrongState:                    Debug.Print "Wrong State"
    Case Aborted:                       Debug.Print "Method Aborted"
    Case FileNotFound:                  Debug.Print "File Not Found"
    Case ValueOverflow:                 Debug.Print "Value Overflow, arithmetic operation that produced a numeric overflow"
    Case AccessDenied:                  Debug.Print "Access Denied"
    Case UnknownImageFormat:            Debug.Print "Unknown Image Format"
    Case FontFamilyNotFound:            Debug.Print "Font Family Not Found"
    Case FontStyleNotFound:             Debug.Print "Font Style Not Found"
    Case NotTrueTypeFont:               Debug.Print "Not TrueType Font"
    Case UnsupportedGdiplusVersion:     Debug.Print "Unsupported Gdiplus Version"
    Case GdiplusNotInitialized:         Debug.Print "Gdiplus Not Initialized"
    Case PropertyNotFound:              Debug.Print "Property Not Found, does not exist in the image"
    Case PropertyNotSupported:          Debug.Print "Property Not Supported, not supported by the format of the image"
    Case ProfileNotFound:               Debug.Print "Profile Not Found, color profile required to save an image in CMYK format was not found"
    Case Else:                          Debug.Print "Error Not Specified"
    End Select
    '
    Stop
End Sub

Y'all Take Care,
Elroy

[RobDog888]

Private Sub ElReturn(GdipReturn As Long)

[SearchingDataOnly]

Private Sub Form_Load()
    '--- Bad readability
    MySub New Class1
    
    '--- Good readability,  but the syntax is not recognized in VB6-IDE
    MySub(New Class1)     '--- Error: Object doesn't support this property or method
    
    '--- Good readability, but a bit verbose
    Call MySub(New Class1)
    
    '--- Useful in special cases, for example: MyFunction(bMultiLine:=True)
    MySub oParam:=New Class1
    
End Sub

Private Sub MySub(oParam As Class1)
    Debug.Assert False
End Sub

In other words, even in the new VB6 compiler, Call still needs to be retained.

[Zvoni]

Private Sub Form_Load()
    '--- Bad readability
    MySub New Class1
    
    '--- Good readability,  but the syntax is not recognized in VB6-IDE
    MySub(New Class1)     '--- Error: Object doesn't support this property or method
    
    '--- Good readability, but a bit verbose
    Call MySub(New Class1)
    
    '--- Useful in special cases, for example: MyFunction(bMultiLine:=True)
    MySub oParam:=New Class1
    
End Sub

Private Sub MySub(oParam As Class1)
    Debug.Assert False
End Sub

In other words, even in the new VB6 compiler, Call still needs to be retained.

Yes, i know: old thread, but out of curiosity:
IMO, the above code is going to leak, since i don't have any chance to destroy the new "class1"

Am i right?

[Arnoutdv]

No, it should be destroyed automatically when going out of scope.

[Zvoni]

No, it should be destroyed automatically when going out of scope.

I know that vb6 is cleaning up after you, but i know from other languages that you have to clean up after yourself.
For all intents and purposes: Imagine vb6 NOT cleaning up after you, would that code leak?

And i consider it "good" practice to destroy everything yourself, that you created (Set MyClass = Nothing)