VB6 vs VB.NET...Procedure Calling Syntax


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 6 123 ... LastLast
Results 1 to 15 of 79

Thread: VB6 vs VB.NET...Procedure Calling Syntax

  1. #1
    Patrick Troughton Guest

    VB6 vs VB.NET...Procedure Calling Syntax


    Here's another example where VB.NET is easier than VB6. If you're joining
    us late, Tuesday we covered how creating a user control is much easier in
    VB.NET.....

    http://news.devx.com/cgi-bin/dnewswe...em=44342&utag=

    Wednesday, we saw how using a file open dialog is easier in VB.NET....

    http://news.devx.com/cgi-bin/dnewswe...em=44447&utag=

    Today, we'll switch to a completely different subject...language syntax.
    Specifically, let's look at how VB.NET syntax for calling a procedure is
    easier than in VB6. This example applies to both beginner and intermediate
    programmers. Advanced programmers probably code them without even thinking
    about it. OK, let's look at VB6 first...

    In VB6, there are five separate rules (plus 2 special cases) for when you
    use parenthesis around an argument list and when you don't. Let's go through
    each rule, one at a time. I'll also provide an example of each because this
    can kind of get confusing.

    Rule 1....Calling a Subroutine with the Call Keyword. When calling a subroutine
    using the Call keyword, you must use parenthesis around the parameter list.
    Example....

    Call MySub(Parm1, Parm2)

    Failure to do so will cause a compile error.

    Rule 2....Calling a Subroutine Without the Call Keyword. When calling a subroutine
    without using the Call keyword, you cannot use parenthesis around the parameter
    list. Example....

    MySub Parm1, Parm2

    If you mistakenly use parenthesis around the parameter list, you will get
    a compile error.

    Rule 3....Calling a Function, Storing the Return Value in a Variable. When
    calling a function and you store the return value into a variable, you must
    use parenthesis around the parameter list. For example.....

    MyReturnValue = MyFunction(Parm1, Parm2)

    Failure to do so will cause a compile error.

    Rule 4....Calling a Function, Ignoring the Return Value. When calling a
    function and you don't use the return value, you cannot use parenthesis.
    For example....

    MyFunction Parm1, Parm2

    If you mistakenly use parenthesis around the parameter list, you will get
    a compile error.

    Rule 5....Calling a Function, Ignoring the Return Value Using the Call Keyword.
    When calling a function, ignoring the return value and using the Call keyword
    you must use parenthesis. For example....

    Call MyFunction(Parm1, Parm2)

    Failure to do so will cause a compile error.

    Rule 6....Calling a Subroutine Without the Call Keyword But with Only One
    Parameter (Special Case of Rule 2). When calling a subroutine that accepts
    only one parameter, and you don't use the Call keyword, you can use a parenthesis.
    However, the behavior now changes such that the parameter is passed by value
    even if the parameter is declared in the subroutine by reference. Example...

    MySub (Parm1)

    This line of code will compile regardless of whether there are parenthesis,
    however the behavior may be different (see above).

    Rule 7....Calling a Function Without the Call Keyword But with Only One Parameter
    Ignoring the Return Value (Special Case of Rule 4). When calling a function
    that accepts only one parameter, and you don't use the Call keyword, you
    can use a parenthesis. However, the behavior now changes such that the parameter
    is passed by value even if the parameter is declared in the function by reference.
    Example:

    MyFunction (Parm1)

    This line of code will compile regardless of whether there are parenthesis,
    however the behavior may be different (see above).

    Now, let's take a lot at VB.NET.

    Rule 1....Always Use Parenthesis.

    Examples:

    MySub (Parm1 Parm2)
    Call MySub(Parm1, Parm2)
    MyReturnValue = MyFunction(Parm1, Parm2)
    MyFunction(Parm1, Parm2)
    Call MyFunction(Parm1, Parm2)
    MySub(Parm1)
    MyFunction(Parm1)

    Forgetting to use the parethesis in VB.NET will not cause a compile error
    because the VB.NET's IntelliSense.

    OK, you be the judge. Which procedure calling syntax do you think is easier
    and why?

    /Pat

  2. #2
    Frank Oquendo Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Patrick Troughton had this to say:

    > Here's another example where VB.NET is easier than VB6. If you're
    > joining us late, Tuesday we covered how creating a user control is
    > much easier in VB.NET.....


    That user control example was hilarious!

    --
    "If you want to be somebody else change your mind"
    http://www.acadx.com
    http://vbxtender.sourceforge.net



  3. #3
    Jens Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Keep this up Patrick, I'm pretty sure that most NOTters will not respond to
    this interesting series, since it is too technical for them. They might
    even finally understand things they have been doing all these years without
    knowing why.

    Jens



  4. #4
    Frank Oquendo Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    DonB had this to say:

    > My rules have always been
    >
    > Call MySub(p1, p2)
    > x = MyFunc(p1, p2)


    The point is that those are *your* rules, not the compiler's.

    > On the other hand, when I first took a stab at writing a simple
    > "ping" app, the complexity of wading through System.Net.Sockets to
    > simply figure out how to specify the IP address raised my blood
    > pressure at least 30 points.


    It really wasn't all that hard to follow. I just read the help.

    > When .NET confronts you with a "fork in the road", it seems like
    > there are at least a dozen paths to choose. Not good.


    There's two ways to look at this:

    1) How is VB's handling of parameters any different?
    2) Since when is flexibility a bad thing?

    --
    "If you want to be somebody else change your mind"
    http://www.acadx.com
    http://vbxtender.sourceforge.net



  5. #5
    DonB Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    My rules have always been

    Call MySub(p1, p2)
    x = MyFunc(p1, p2)

    Never, ever, been any trouble. Never, ever, been any confusion. Never,
    ever, been any concern.

    On the other hand, when I first took a stab at writing a simple "ping" app,
    the complexity of wading through System.Net.Sockets to simply figure out how
    to specify the IP address raised my blood pressure at least 30 points.

    When .NET confronts you with a "fork in the road", it seems like there are
    at least a dozen paths to choose. Not good.






  6. #6
    Patrick Troughton Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax


    AFAIK, it doesn't matter whether the procedure is user-created or built-in
    to the language. In VB6, all 7 rules apply equally. In VB.NET, there's still
    only one rule. Unless you're trying to say that the rules change depending
    on whether the procedure is user-created or built-in? If so, then the rules
    governing VB6 procedure calling syntax are even more complicated that I thought...

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >Patrick,
    >
    >When Subs were introduced and allowed to be called without the Call
    >keyword, the intent was to allow you to create "new statements". User
    >defined extensions... good idea before their time, eh?
    >
    >The syntax for using a statement (whether you created it using Sub or
    >it were a Basic statement) were the same.
    >
    > MyStatement Arg1, Arg2, Arg3 'yada yada
    >
    >So, now that we've established that it must be better to enclose
    >argument lists in parens in all cases, should we now expect MS to
    >change the syntax on the remainder of statements so that they use
    >parens (yea, more like C). Yea, that sounds about right to me based
    >on what they've done so far.
    >
    > Debug.Print("This Change Makes Sense:",False)
    >
    >>OK, you be the judge. Which procedure calling syntax do you think is easier
    >>and why?

    >
    >OK, you be the judge. When you see the statement
    >
    > Printf (MyVar)
    >
    >is MyVar being passed "byval" or not? It depends on whether Printf is
    >an internal keyword (you do remember them all don't you?)... as
    >opposed to an explicit indicator like Call.
    >
    >YeaRight.
    >
    >Dan
    >



  7. #7
    Dan Barclay Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Patrick,

    When Subs were introduced and allowed to be called without the Call
    keyword, the intent was to allow you to create "new statements". User
    defined extensions... good idea before their time, eh?

    The syntax for using a statement (whether you created it using Sub or
    it were a Basic statement) were the same.

    MyStatement Arg1, Arg2, Arg3 'yada yada

    So, now that we've established that it must be better to enclose
    argument lists in parens in all cases, should we now expect MS to
    change the syntax on the remainder of statements so that they use
    parens (yea, more like C). Yea, that sounds about right to me based
    on what they've done so far.

    Debug.Print("This Change Makes Sense:",False)

    >OK, you be the judge. Which procedure calling syntax do you think is easier
    >and why?


    OK, you be the judge. When you see the statement

    Printf (MyVar)

    is MyVar being passed "byval" or not? It depends on whether Printf is
    an internal keyword (you do remember them all don't you?)... as
    opposed to an explicit indicator like Call.

    YeaRight.

    Dan



    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  8. #8
    Frank Oquendo Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Dan Barclay had this to say:

    > OK, you be the judge. When you see the statement
    >
    > Printf (MyVar)
    >
    > is MyVar being passed "byval" or not? It depends on whether Printf is
    > an internal keyword (you do remember them all don't you?)... as
    > opposed to an explicit indicator like Call.


    Um... wouldn't that be defined by the function you're calling? And isn't
    that as it should be? Your example points out the problem with such loose
    rules: the code does not make itself immediately apparent. Modifiers such as
    out and ref make it crystal clear how an argument is being passed.

    --
    "If you want to be somebody else change your mind"
    http://www.acadx.com
    http://vbxtender.sourceforge.net



  9. #9
    MMFAN Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax


    I thought it was pretty funny myself.

    "Frank Oquendo" <nospam@please.com> wrote:
    >Patrick Troughton had this to say:
    >
    >> Here's another example where VB.NET is easier than VB6. If you're
    >> joining us late, Tuesday we covered how creating a user control is
    >> much easier in VB.NET.....

    >
    >That user control example was hilarious!
    >
    >--
    >"If you want to be somebody else change your mind"
    >http://www.acadx.com
    >http://vbxtender.sourceforge.net
    >
    >



  10. #10
    MMFAN Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax


    Ha you wish!

    You fit right in with the rest of the poor scared .Netters who can't deal
    with reasonable arguments. Weren't you compaining about all the negativity
    in this discussion? Way to fuel the fire.

    "Jens" <jens@esalar.be> wrote:
    >Keep this up Patrick, I'm pretty sure that most NOTters will not respond

    to
    >this interesting series, since it is too technical for them. They might
    >even finally understand things they have been doing all these years without
    >knowing why.
    >
    >Jens
    >
    >



  11. #11
    Daniel Pratt Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Hi Dan,

    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news8c5lu42r5k8kae7r6i3q1nnl8996n3le0@4ax.com...
    > Patrick,
    >
    > When Subs were introduced and allowed to be called without the Call
    > keyword, the intent was to allow you to create "new statements". User
    > defined extensions... good idea before their time, eh?
    >
    > The syntax for using a statement (whether you created it using Sub or
    > it were a Basic statement) were the same.
    >
    > MyStatement Arg1, Arg2, Arg3 'yada yada
    >
    > So, now that we've established that it must be better to enclose
    > argument lists in parens in all cases, should we now expect MS to
    > change the syntax on the remainder of statements so that they use
    > parens (yea, more like C). Yea, that sounds about right to me based
    > on what they've done so far.


    You've just brought to mind yet another thing I think is a big
    improvement in VB.NET (vs. VB6): No more statements with special syntax
    rules like Mid, Write, Print and most abhorrently, Line (ironically,
    intellisense would be exceptionally useful here but there is none). Of
    course, there are still things like AddHandler and CType, which look a lot
    like methods but aren't, but it's progress.

    Regards,
    Dan



  12. #12
    Frank Oquendo Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    Dan Barclay had this to say:

    > Nope, *you're* saying the rules change (require or don't require
    > parens) depending on whether the precedure is user-created or built-in
    > for VB.net so far as I can tell. But, maybe I misunderstood.


    <quote>
    Rule 1....Always Use Parenthesis.
    </quote>

    I think you misunderstood.

    --
    "If you want to be somebody else change your mind"
    http://www.acadx.com
    http://vbxtender.sourceforge.net



  13. #13
    Dan Barclay Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax

    On 8 Aug 2002 11:04:05 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >AFAIK, it doesn't matter whether the procedure is user-created or built-in
    >to the language. In VB6, all 7 rules apply equally. In VB.NET, there's still
    >only one rule.


    Sorry, I don't follow your "new rules".

    In VB6, if you see a statement without a Call keyword in front of it
    then its argument list needs no parens surrounding it. That is the
    case whether it's a built-in statement or a user Sub.

    Sorry, but that seems *real* simple to me.

    Now, the issue of whether an *individual argument* has parens around
    it is a separate issue applied to each argument. If you want a copy
    of the variable (or expression), you enclose an individual argument in
    parens (aka "byval").

    >Unless you're trying to say that the rules change depending
    >on whether the procedure is user-created or built-in? If so, then the rules
    >governing VB6 procedure calling syntax are even more complicated that I thought...


    Nope, *you're* saying the rules change (require or don't require
    parens) depending on whether the precedure is user-created or built-in
    for VB.net so far as I can tell. But, maybe I misunderstood.

    Dan


    >Dan Barclay <Dan@MVPs.org> wrote:
    >>Patrick,
    >>
    >>When Subs were introduced and allowed to be called without the Call
    >>keyword, the intent was to allow you to create "new statements". User
    >>defined extensions... good idea before their time, eh?
    >>
    >>The syntax for using a statement (whether you created it using Sub or
    >>it were a Basic statement) were the same.
    >>
    >> MyStatement Arg1, Arg2, Arg3 'yada yada
    >>
    >>So, now that we've established that it must be better to enclose
    >>argument lists in parens in all cases, should we now expect MS to
    >>change the syntax on the remainder of statements so that they use
    >>parens (yea, more like C). Yea, that sounds about right to me based
    >>on what they've done so far.
    >>
    >> Debug.Print("This Change Makes Sense:",False)
    >>
    >>>OK, you be the judge. Which procedure calling syntax do you think is easier
    >>>and why?

    >>
    >>OK, you be the judge. When you see the statement
    >>
    >> Printf (MyVar)
    >>
    >>is MyVar being passed "byval" or not? It depends on whether Printf is
    >>an internal keyword (you do remember them all don't you?)... as
    >>opposed to an explicit indicator like Call.
    >>
    >>YeaRight.
    >>
    >>Dan
    >>


    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  14. #14
    MMFAN Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax


    IF this is really what you guys wanted all along, then you should have just
    used Pascal, C or Java... oh yeah those languages are hard to use.

    "Frank Oquendo" <nospam@please.com> wrote:
    >Dan Barclay had this to say:
    >
    >> OK, you be the judge. When you see the statement
    >>
    >> Printf (MyVar)
    >>
    >> is MyVar being passed "byval" or not? It depends on whether Printf is
    >> an internal keyword (you do remember them all don't you?)... as
    >> opposed to an explicit indicator like Call.

    >
    >Um... wouldn't that be defined by the function you're calling? And isn't
    >that as it should be? Your example points out the problem with such loose
    >rules: the code does not make itself immediately apparent. Modifiers such

    as
    >out and ref make it crystal clear how an argument is being passed.
    >
    >--
    >"If you want to be somebody else change your mind"
    >http://www.acadx.com
    >http://vbxtender.sourceforge.net
    >
    >



  15. #15
    Patrick Troughton Guest

    Re: VB6 vs VB.NET...Procedure Calling Syntax


    Dan Barclay <Dan@MVPs.org> wrote:
    >On 8 Aug 2002 11:04:05 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>AFAIK, it doesn't matter whether the procedure is user-created or built-in
    >>to the language. In VB6, all 7 rules apply equally. In VB.NET, there's

    still
    >>only one rule.

    >
    >Sorry, I don't follow your "new rules".


    I'm not sure what you mean. Are you talking about VB6 or VB.NET?

    If VB.NET...there's only one rule.

    If VB6...then there are several rules but they're not new. That's the way
    it's been for years. And you *must* follow them if you want your VB6 code
    to run.

    In any case, they're not my rules. They're the compiler's rules.

    >In VB6, if you see a statement without a Call keyword in front of it
    >then its argument list needs no parens surrounding it.


    I agree.

    > That is the
    >case whether it's a built-in statement or a user Sub.


    I agree.

    >Sorry, but that seems *real* simple to me.


    Which part? Just rule 1 or all five (plus the two special cases)?

    >Now, the issue of whether an *individual argument* has parens around
    >it is a separate issue applied to each argument. If you want a copy
    >of the variable (or expression), you enclose an individual argument in
    >parens (aka "byval").


    Correct. I mentioned that under VB6's rule 6 (special case of rule 2) and
    VB6's rule 7 (special case of rule 4).

    >Nope, *you're* saying the rules change (require or don't require
    >parens) depending on whether the precedure is user-created or built-in
    >for VB.net so far as I can tell.


    No, I thought that's what you were trying to tell me.

    >But, maybe I misunderstood.


    Yes, I think we both did. In fact, I still don't understand what you were
    trying to say. I guess the part that confused me is when you said....

    <quote>
    When you see the statement

    Printf (MyVar)

    is MyVar being passed "byval" or not? It depends on whether Printf is
    an internal keyword (you do remember them all don't you?)... as
    opposed to an explicit indicator like Call.
    </quote>

    Maybe I'm being dense but it sure sure sounds like you're saying that what
    happens depends on whether it's an internal keyword or not.. What else does
    "It depends on whether Printf is an internal keyword..." mean? Also, the
    last part of your last sentence doesn't make any sense. You can use the Call
    keyword to call a built-in function of VB6. For example...

    Randomize
    Call Randomize

    Both of these compile just fine in VB6. Try it yourself.

    /Pat

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