-
Jan 12th, 2018, 06:46 AM
#1
Thread Starter
Addicted Member
Any technical reason not to use Call in VB6?
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.
-
Jan 12th, 2018, 06:59 AM
#2
Re: Any technical reason not to use Call in VB6?
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..
-
Jan 12th, 2018, 07:15 AM
#3
Re: Any technical reason not to use Call in VB6?
http://bbs.vbstreets.ru/viewtopic.php?f=68&t=43984
Code:
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.
-
Jan 12th, 2018, 07:29 AM
#4
Thread Starter
Addicted Member
Re: Any technical reason not to use Call in VB6?
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.
-
Jan 12th, 2018, 10:02 AM
#5
Re: Any technical reason not to use Call in VB6?
Thread moved from CodeBank, which is for finished code snippets rather than questions.
My usual boring signature: Nothing
-
Jan 12th, 2018, 10:19 AM
#6
Re: Any technical reason not to use Call in VB6?
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
-
Jan 12th, 2018, 10:59 AM
#7
Re: Any technical reason not to use Call in VB6?
You don't need to use the archaic Call statement to invoke a Function.
-
Jan 12th, 2018, 11:05 AM
#8
Fanatic Member
Re: Any technical reason not to use Call in VB6?
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.
-
Jan 12th, 2018, 11:07 AM
#9
Re: Any technical reason not to use Call in VB6?
"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.
-
Jan 12th, 2018, 11:21 AM
#10
Re: Any technical reason not to use Call in VB6?
Originally Posted by 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.
That's why I used to use it.
-
Feb 22nd, 2021, 04:34 AM
#11
Re: Any technical reason not to use Call in VB6?
Originally Posted by Phill.W
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.
This, exactly.
-
Jan 12th, 2018, 11:19 AM
#12
Re: Any technical reason not to use Call in VB6?
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.
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
Microsoft MVP 2006-2011
Office Development FAQ (C#, VB.NET, VB 6, VBA)
Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
If a post has helped you then Please Rate it!
• Reps & Rating Posts • VS.NET on Vista • Multiple .NET Framework Versions • Office Primary Interop Assemblies • VB/Office Guru™ Word SpellChecker™.NET • VB/Office Guru™ Word SpellChecker™ VB6 • VB.NET Attributes Ex. • Outlook Global Address List • API Viewer utility • .NET API Viewer Utility •
System: Intel i7 6850K, Geforce GTX1060, Samsung M.2 1 TB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2016, VS 2019, VB6 SP6
-
Jan 12th, 2018, 11:24 AM
#13
Re: Any technical reason not to use Call in VB6?
is there any difference in the compiled executable when using "call" to call a function?
-
Jan 12th, 2018, 11:26 AM
#14
Re: Any technical reason not to use Call in VB6?
None at all.
Regards, Phill W.
-
Jan 12th, 2018, 11:25 AM
#15
Re: Any technical reason not to use Call in VB6?
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
-
Jan 12th, 2018, 11:59 AM
#16
Re: Any technical reason not to use Call in VB6?
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.
Last edited by Elroy; Jan 12th, 2018 at 01:41 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Jan 12th, 2018, 01:02 PM
#17
Re: Any technical reason not to use Call in VB6?
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
-
Jan 12th, 2018, 01:49 PM
#18
Re: Any technical reason not to use Call in VB6?
-
Jan 12th, 2018, 01:56 PM
#19
Re: Any technical reason not to use Call in VB6?
Code:
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
-
Jan 12th, 2018, 02:15 PM
#20
Re: Any technical reason not to use Call in VB6?
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?
-
Jan 12th, 2018, 02:34 PM
#21
Re: Any technical reason not to use Call in VB6?
Originally Posted by 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?
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.
-
Jan 12th, 2018, 02:51 PM
#22
Re: Any technical reason not to use Call in VB6?
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.
-
Jan 12th, 2018, 10:58 PM
#23
Re: Any technical reason not to use Call in VB6?
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
-
Jan 12th, 2018, 11:21 PM
#24
Re: Any technical reason not to use Call in VB6?
I believe it makes the code more readable/understandable
-
Jan 13th, 2018, 08:20 AM
#25
Re: Any technical reason not to use Call in VB6?
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
Code:
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.
Last edited by dreammanor; Jan 13th, 2018 at 08:32 AM.
-
Jan 13th, 2018, 08:25 AM
#26
Re: Any technical reason not to use Call in VB6?
sorry, deleted the duplicate post.
Last edited by dreammanor; Jan 13th, 2018 at 08:33 AM.
-
Jan 13th, 2018, 07:11 PM
#27
Re: Any technical reason not to use Call in VB6?
Last edited by dz32; Apr 26th, 2019 at 11:26 AM.
-
Jan 17th, 2018, 11:52 AM
#28
New Member
Re: Any technical reason not to use Call in VB6?
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
-
Apr 3rd, 2018, 11:13 AM
#29
Re: Any technical reason not to use Call in VB6?
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
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Apr 4th, 2018, 02:38 AM
#30
Re: Any technical reason not to use Call in VB6?
Originally Posted by 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.)
Elroy
Pretty much what I said back in post 6, although I didn't explain it in as much depth.
J.A. Coutts
-
Apr 4th, 2018, 09:05 AM
#31
Re: Any technical reason not to use Call in VB6?
Originally Posted by Elroy
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?
Code:
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.
-
Apr 4th, 2018, 09:33 AM
#32
Re: Any technical reason not to use Call in VB6?
Originally Posted by dilettante
I don't expect anyone to change his mind based on my recommendation though.
----
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Apr 3rd, 2018, 11:19 AM
#33
Re: Any technical reason not to use Call in VB6?
that's how the C++ class wrappers work. they save the last error code using SetStatus().
Graphics.cls
Code:
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
-
Apr 3rd, 2018, 07:36 PM
#34
Re: Any technical reason not to use Call in VB6?
Originally Posted by 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
Golang allows functions to return multiple values. That feature is useful.
-
Apr 4th, 2018, 01:39 PM
#35
Re: Any technical reason not to use Call in VB6?
Using Call is just uncalled for
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
Microsoft MVP 2006-2011
Office Development FAQ (C#, VB.NET, VB 6, VBA)
Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
If a post has helped you then Please Rate it!
• Reps & Rating Posts • VS.NET on Vista • Multiple .NET Framework Versions • Office Primary Interop Assemblies • VB/Office Guru™ Word SpellChecker™.NET • VB/Office Guru™ Word SpellChecker™ VB6 • VB.NET Attributes Ex. • Outlook Global Address List • API Viewer utility • .NET API Viewer Utility •
System: Intel i7 6850K, Geforce GTX1060, Samsung M.2 1 TB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2016, VS 2019, VB6 SP6
-
Apr 4th, 2018, 08:31 PM
#36
Re: Any technical reason not to use Call in VB6?
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.
Code:
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
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Feb 22nd, 2021, 04:39 AM
#37
Re: Any technical reason not to use Call in VB6?
Originally Posted by Elroy
I built this little function that I now use. I replaced all my "Call" statements with that little "Retn" procedure, all all for dilettante.
Thanks for raising this post from the dead, sometimes a little gem re-emerges.
Last edited by yereverluvinuncleber; Feb 22nd, 2021 at 05:12 AM.
-
Apr 5th, 2018, 01:52 PM
#38
Re: Any technical reason not to use Call in VB6?
Private Sub ElReturn(GdipReturn As Long)
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
Microsoft MVP 2006-2011
Office Development FAQ (C#, VB.NET, VB 6, VBA)
Senior Jedi Software Engineer MCP (VB 6 & .NET), BSEE, CET
If a post has helped you then Please Rate it!
• Reps & Rating Posts • VS.NET on Vista • Multiple .NET Framework Versions • Office Primary Interop Assemblies • VB/Office Guru™ Word SpellChecker™.NET • VB/Office Guru™ Word SpellChecker™ VB6 • VB.NET Attributes Ex. • Outlook Global Address List • API Viewer utility • .NET API Viewer Utility •
System: Intel i7 6850K, Geforce GTX1060, Samsung M.2 1 TB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2016, VS 2019, VB6 SP6
-
Feb 22nd, 2021, 01:46 AM
#39
Re: Any technical reason not to use Call in VB6?
Code:
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.
Last edited by SearchingDataOnly; Feb 22nd, 2021 at 01:56 AM.
-
Feb 22nd, 2021, 02:14 AM
#40
Re: Any technical reason not to use Call in VB6?
Originally Posted by SearchingDataOnly
Code:
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?
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|