DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 42

Thread: Using the Call statement

  1. #1
    Eric D. Burdo Guest

    Using the Call statement


    Recently a colleague of mine stated that calling API function w/out storing
    the return value, or using the call statement, can lead to GPF’s.

    Here is an example:

    BAD:
    VerQueryValue tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize

    GOOD:
    Call VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    lR = VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)

    So, my question is. Is my colleague correct? Can not assigning the result
    cause problems?


  2. #2
    Ken Halter Guest

    Re: Using the Call statement

    > So, my question is. Is my colleague correct? Can not assigning the
    result
    > cause problems?

    Absolutely NOT.. smack him around a bit for adding confusion to a simple
    case of "I don't care what the result is.. so don't store it"... There's an
    intermediate buffer that stores the result.. that will be transferred to
    your variable if you want.. nothing requires this... it's the same as
    calling a function in your VB program.

    > Call VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    > lR = VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)

    FWIW.. I prefer the prepending Call (strictly personal choice)... makes the
    code look more consistant than adding / removing parens..

    --
    Ken Halter
    MS-MVP-VB
    http://www.vbsight.com
    Please respond only to the newsgroups so all can benefit.
    Besides.. I check my email only once a week :-)

    "Eric D. Burdo" <eric.burdo@atxinc.com> wrote in message
    news:3c20d5e4$1@147.208.176.211...
    >
    > Recently a colleague of mine stated that calling API function w/out

    storing
    > the return value, or using the call statement, can lead to GPF's.
    >
    > Here is an example:
    >
    > BAD:
    > VerQueryValue tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize
    >
    > GOOD:
    > Call VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    > lR = VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    >
    > So, my question is. Is my colleague correct? Can not assigning the

    result
    > cause problems?
    >




  3. #3
    Bob Butler Guest

    Re: Using the Call statement


    "Eric D. Burdo" <eric.burdo@atxinc.com> wrote in message
    news:3c20d5e4$1@147.208.176.211...
    >
    > Recently a colleague of mine stated that calling API function w/out

    storing
    > the return value, or using the call statement, can lead to GPF’s.
    >
    > Here is an example:
    >
    > BAD:
    > VerQueryValue tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize
    >
    > GOOD:
    > Call VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    > lR = VerQueryValue(tVerBuf(0), "\" & vbNullString, lpBufPtr, lFreeSize)
    >
    > So, my question is. Is my colleague correct? Can not assigning the

    result
    > cause problems?


    I vaguely remember hearing about a case in VB3 or VB4 where not assigning
    the return value could result in a memory leak. I don't remember if it was
    verified or not but as far as I know there is no issue with it in VB5 or
    VB6.

    I prefer to actually assign it to a temporary variable, even if just so I
    can check during debugging that I got what came back. Also because it's a
    little less confusing to people if functions are always treated like
    functions and not functions some times and subs other times. I do, however,
    use all 3 syntaxes depending on what seems best in the specific circumstance
    (e.g. the MsgBox function is often called as if it were a statement or a
    sub). Agree with your colleague when he says that and then do it whatever
    way you want ! <g>




  4. #4
    Ken Halter Guest

    Re: Using the Call statement

    "Bob Butler" <butlerbob@earthlink.net> wrote in message
    news:3c20e5b8@147.208.176.211...
    >
    > (e.g. the MsgBox function is often called as if it were a statement or a

    sub).

    I'm one of those... and MsgBox is a perfect example of ignoring a result..

    > Agree with your colleague when he says that and then do it whatever
    > way you want ! <g>


    Excellent suggestion.. I used to use that technique on my parents. <g>


    --
    Ken Halter
    MS-MVP-VB
    http://www.vbsight.com
    Please respond only to the newsgroups so all can benefit.
    Besides.. I check my email only once a week :-)




  5. #5
    Phil Weber Guest

    Re: Using the Call statement

    > I'm one of those... and MsgBox is a perfect example
    > of ignoring a result.


    No! Any call to MsgBox in which you ignore the result should be removed from
    your code! Interrupting the user with a modal dialog whose only option is
    "OK" is just plain rude. Find a more polite way to communicate with your
    users!
    ---
    Phil Weber
    (Tongue only partially in cheek)



  6. #6
    Ken Halter Guest

    Re: Using the Call statement

    Looks like a case of personal choice.. I doubt I'll be removing my MsgBox
    statements any time soon.. It's not like they're there for nothing.. If I
    feel that a message is better suited in a label or textbox, that's where it
    goes.. If there's a message that's important enough to pop up a simple
    dialog so the user can't simply ignore it, I choose a message box.

    Rude... is when you're browsing on a web site that pops up several un-needed
    windows trying to sell you something and while you're viewing or taking the
    time to close these windows, code in their page is stealing your email
    address so they can spam you until you die.. a message box isn't rude.

    --
    Ken Halter
    MS-MVP-VB
    http://www.vbsight.com
    Please respond only to the newsgroups so all can benefit.
    Besides.. I check my email only once a week :-)

    "Phil Weber" <pweberonline@fawcette.com> wrote in message
    news:3c20f1f2$1@147.208.176.211...
    > > I'm one of those... and MsgBox is a perfect example
    > > of ignoring a result.

    >
    > No! Any call to MsgBox in which you ignore the result should be removed

    from
    > your code! Interrupting the user with a modal dialog whose only option is
    > "OK" is just plain rude. Find a more polite way to communicate with your
    > users!
    > ---
    > Phil Weber
    > (Tongue only partially in cheek)
    >
    >




  7. #7
    Bob Butler Guest

    Re: Using the Call statement


    "Phil Weber" <pweberonline@fawcette.com> wrote in message
    news:3c20f1f2$1@147.208.176.211...
    > > I'm one of those... and MsgBox is a perfect example
    > > of ignoring a result.

    >
    > No! Any call to MsgBox in which you ignore the result should be removed

    from
    > your code! Interrupting the user with a modal dialog whose only option is
    > "OK" is just plain rude. Find a more polite way to communicate with your
    > users!
    > ---
    > Phil Weber
    > (Tongue only partially in cheek)


    I don't disagree with that as a general rule. A lot of what I've been doing
    recently has been relatively long-running processes during which I expect
    the user to switch to other apps while it runs. When it ends there's
    nothing left to to except to display a message regarding success/failure so
    "OK" is the only option and a messagebox works just as well as anything
    else.

    In other cases, like form-level validation, it may be appropriate to display
    a list of problems with only "OK" as an option. I hate apps that yell at me
    with every field but there are places where a message box can be appropriate
    without caring about the result.






  8. #8
    Anthony Jones Guest

    Re: Using the Call statement

    Hmm... some one has been reading Cooper. :-)

    --
    Anthony Jones
    Nuesoft Ltd




  9. #9
    Phil Weber Guest

    Re: Using the Call statement

    > ...there are places where a message box can be appropriate
    > without caring about the result.


    Bob: I agree, but in my opinion such cases are extremely rare, much less
    common than the frequency with with programmers typically pepper their code
    with MsgBox statements.

    > A lot of what I've been doing recently has been relatively long-
    > running processes during which I expect the user to switch to other
    > apps while it runs. When it ends there's nothing left to do except
    > to display a message regarding success/failure so "OK" is the only
    > option and a messagebox works just as well as anything else.


    Why not play a sound? Or bring your app's window to the foreground? (Modern
    versions of Windows give the user the option of preventing a background app
    from stealing the focus, and instead Windows flashes the app's taskbar icon.
    Wouldn't that be a less intrusive way to alert the user that a lengthy
    process has completed?)
    ---
    Phil Weber



  10. #10
    Phil Weber Guest

    Re: Using the Call statement

    > Looks like a case of personal choice...

    Ken: Agreed. What I've stated are my opinions. But I'm confident in their
    correctness because I've never met a user who prefers a MsgBox after having
    seen alternative methods of communication.

    > If there's a message that's important enough to pop up
    > a simple dialog so the user can't simply ignore it, I choose
    > a message box.


    What sorts of messages do you consider sufficiently important that they
    justify interrupting the user?
    ---
    Phil Weber



  11. #11
    Mattias Sjögren Guest

    Re: Using the Call statement

    Eric,

    FWIW, there is actually a crash bug in VB6 that occurs when you *do*
    use Call, not otherwise. But it only happens for a very limited set of
    API functions, so you can probably ignore it.


    Mattias

    ===
    Mattias Sjögren (VB MVP)

  12. #12
    Bob Butler Guest

    Re: Using the Call statement


    "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
    news:3c2108ed$1@147.208.176.211...
    > Eric,
    >
    > FWIW, there is actually a crash bug in VB6 that occurs when you *do*
    > use Call, not otherwise. But it only happens for a very limited set of
    > API functions, so you can probably ignore it.


    Do you have a reference or more info? I don't remember seeing that.




  13. #13
    Bob Butler Guest

    Re: Using the Call statement


    "Phil Weber" <pweberonline@fawcette.com> wrote in message
    news:3c210494$1@147.208.176.211...
    <cut>
    > Why not play a sound? Or bring your app's window to the foreground?


    Well, the particular process I was thinking about is actually VBScript, not
    VB, and I took the easy way out <g>

    I don't think we disagree in principle, maybe just a little in the matter of
    degree. I do avoid MsgBox in most cases and I'm now kind of sorry I brought
    it up<g>. It's just a good example since it's familiar even to newbies and
    is often used with and without the return values.




  14. #14
    Bob Butler Guest

    Re: Using the Call statement


    "Phil Weber" <pweberonline@fawcette.com> wrote in message
    news:3c210494$1@147.208.176.211...
    <cut>
    > Why not play a sound?


    BTW, the one thing that drives me right up the wall is apps that make
    sounds. I always have the sound disabled unless I have something I
    specifically want to play. Sounds are MUCH more annoying than any number of
    message noxes IMO.

    The best option is to make the choice of alerts user-configurable; sound,
    message box, flashing caption, whatever...

    As an aside... I noticed after installing VS.net beta 2 and the required IE
    6/explorer updates that I can no longer disable the speaker. It works until
    I reboot at which time it becomes enabled again. I had to resort to putting
    something in the startup group to kill it. ^&%$%$%^&^ Microsoft!




  15. #15
    Phil Weber Guest

    Re: Using the Call statement

    > ...and I took the easy way out <g>

    Bob: And that's really the bottom line. I have no problem with MsgBox if it
    improves the user's experience, but I'm hard-pressed to think of cases where
    it does. In the overwhelming majority of cases, MsgBox is used to make the
    programmer's job easier, not the user's, and that's why I'm opposed to it.
    ---
    Phil Weber



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center