Any technical reason not to use Call in VB6?-VBForums
Results 1 to 27 of 27

Thread: Any technical reason not to use Call in VB6?

  1. #1

    Thread Starter
    Member
    Join Date
    Jul 2016
    Posts
    39

    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.

  2. #2
    Fanatic Member
    Join Date
    Jun 2012
    Posts
    898

    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..

  3. #3

  4. #4

    Thread Starter
    Member
    Join Date
    Jul 2016
    Posts
    39

    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.

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,334

    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

  6. #6
    Hyperactive Member
    Join Date
    Dec 2012
    Posts
    453

    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

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    18,065

    Re: Any technical reason not to use Call in VB6?

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

  8. #8
    Addicted Member
    Join Date
    Feb 2017
    Posts
    141

    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.

  9. #9
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    581

    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.

  10. #10
    Super Moderator RobDog888's Avatar
    Join Date
    Apr 2001
    Location
    LA, Calif. Raiders #1 AKA:Gangsta Yoda™
    Posts
    60,529

    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!
    Star Wars Gangsta Rap Reps & Rating PostsVS.NET on Vista Multiple .NET Framework Versions Office Primary Interop AssembliesVB/Office Guru™ Word SpellChecker™.NETVB/Office Guru™ Word SpellChecker™ VB6VB.NET Attributes Ex.Outlook Global Address ListAPI Viewer utility.NET API Viewer Utility
    System: Intel i7 6850K, Corsair H100i v2 water cooler, Geforce GTX1060, Samsung M.2 500 GB & SATA 500 GB, 32 GBs DDR4 3300 Quad Channel RAM, 2 Viewsonic 24" LCDs, Windows 10, Office 2010, VS 2010

  11. #11
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,684

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by Phill.W View Post
    "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.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  12. #12
    Hyperactive Member
    Join Date
    Dec 2014
    Posts
    389

    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?

  13. #13
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,350

    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
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    581

    Re: Any technical reason not to use Call in VB6?

    None at all.

    Regards, Phill W.

  15. #15
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    3,432

    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. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  16. #16
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    16,903

    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
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  17. #17
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    682

    Re: Any technical reason not to use Call in VB6?

    Occam's razor
    MSDN online for VB6 - Language Reference - Controls Reference
    Download MSDN October 2001: disk 1, 2 and 3

  18. #18

  19. #19
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    16,903

    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?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  20. #20
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,684

    Re: Any technical reason not to use Call in VB6?

    Quote Originally Posted by LaVolpe View Post
    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.
    Imagine what it would be like to set breakpoints in, or step through subclassing code;
    and then being able to hit stop/end/debug or continue, without crashing the IDE.

    VB6.tlb | Bulletproof Subclassing in the IDE (no thunks/assembly/DEP issues)

  21. #21

  22. #22
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    12,203

    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

  23. #23
    Frenzied Member
    Join Date
    Dec 2008
    Posts
    1,081

    Re: Any technical reason not to use Call in VB6?

    I believe it makes the code more readable/understandable

  24. #24
    Fanatic Member
    Join Date
    Sep 2012
    Posts
    549

    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.

  25. #25
    Fanatic Member
    Join Date
    Sep 2012
    Posts
    549

    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.

  26. #26
    Addicted Member
    Join Date
    Jun 2015
    Posts
    151

    Re: Any technical reason not to use Call in VB6?

    i use call once in a while if I am calling a sub with no arguments and want to make it clear that its a procedure call

  27. #27
    New Member
    Join Date
    Jan 2018
    Posts
    2

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.