VB6 vs VB.NET...Procedure Calling Syntax - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 6 FirstFirst 1234 ... LastLast
Results 16 to 30 of 79

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

  1. #16
    Daniel Pratt Guest

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

    Hi Dan,

    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:1lg5luggslh0bkir44opsdrr4764lgg7iq@4ax.com...
    <snip>
    > 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.


    Well, its already more complicated than it needs to be and you haven't
    mentioned the case of when you are assigning a return value to a variable,
    which complicates it even further.

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


    At some point we have a function call like this:

    If GetMyObject(myObjectVar) Then

    myObjectVar.DoStuff

    End If

    At a later date we decide that GetMyObject needs to raise an error if
    something goes wrong instead of returning False, so...<cut>...<cut>...

    GetMyObject (myObjectVar)
    myObjectVar.DoStuff

    "Object or with variable not set." What the...! Oh yea, I forgot to
    remove the parens, silly me.

    Regards,
    Dan



  2. #17
    Daniel Pratt Guest

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

    Hi MMFAN,

    "MMFAN" <mmf@mmf.org> wrote in message news:3d52c775$1@10.1.10.29...
    >
    > 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.


    I like VB6 *despite* the syntax, not because of it.

    Regards,
    Dan



  3. #18
    Dan Barclay Guest

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

    On Thu, 8 Aug 2002 14:19:39 -0500, "Frank Oquendo" <nospam@please.com>
    wrote:

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


    Like in:

    Debug.Print (Expr1, Epr2, etc...)

    Right?

    Yea, that makes sense. Can't wait for the next round of language
    changes to make it so. LOL

    Dan

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

  4. #19
    Dan Barclay Guest

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

    On Thu, 8 Aug 2002 15:50:26 -0400, "Daniel Pratt"
    <dprREMOVETHISatt71@hotmail.com> wrote:

    >Hi Dan,
    >
    >"Dan Barclay" <Dan@MVPs.org> wrote in message
    >news:1lg5luggslh0bkir44opsdrr4764lgg7iq@4ax.com...
    ><snip>
    >> 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.

    >
    > Well, its already more complicated than it needs to be and you haven't
    >mentioned the case of when you are assigning a return value to a variable,
    >which complicates it even further.


    In case you haven't figured it out yet: Neither environments are
    completely consistent. It's a matter of what you choose to attach
    your need for consistency to.

    Changing the way it behaves didn't improve anything, it only changed
    it.

    Maybe in the next round of changes they'll make everything consistent
    (nobody will mind rewriting again from what I can surmise). Then
    again, maybe the next round will only be a hodgepodge of changes like
    this one.

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

  5. #20
    Daniel Pratt Guest

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

    Hi Dan,

    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:a4l5luk2ls9oq64s9obm5q3uvj4nte7ll6@4ax.com...
    >
    > In case you haven't figured it out yet: Neither environments are
    > completely consistent. It's a matter of what you choose to attach
    > your need for consistency to.


    I pointed out some (of what I consider to be) inconsistencies within
    VB.NET in a recent post. Btw, you seem to be alluding (in your typically
    obtuse fashion) to a particular inconsistency in VB.NET having to do with
    procedure calls. Please elucidate.

    > Changing the way it behaves didn't improve anything, it only changed
    > it.


    I consider that *more* consistent is better.

    > Maybe in the next round of changes they'll make everything consistent
    > (nobody will mind rewriting again from what I can surmise). Then
    > again, maybe the next round will only be a hodgepodge of changes like
    > this one.


    I don't consider that making major changes to a language every version
    is wise, but neither do I think that maintaining 100% compatibility with all
    previous versions is wise. Well, more correctly, I think that there is a
    place for nearly 100% backwords compatible languages, but clearly VB does
    not attempt to fill that niche.

    Regards,
    Dan



  6. #21
    Dan Barclay Guest

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

    On Thu, 8 Aug 2002 17:18:15 -0400, "Daniel Pratt"
    <dprREMOVETHISatt71@hotmail.com> wrote:

    >> In case you haven't figured it out yet: Neither environments are
    >> completely consistent. It's a matter of what you choose to attach
    >> your need for consistency to.

    >
    > I pointed out some (of what I consider to be) inconsistencies within
    >VB.NET in a recent post. Btw, you seem to be alluding (in your typically
    >obtuse fashion) to a particular inconsistency in VB.NET having to do with
    >procedure calls. Please elucidate.


    Yea, what I posted was obtuse to folks that want to ignore it:
    ======================
    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)
    ======================

    >> Changing the way it behaves didn't improve anything, it only changed
    >> it.

    >
    > I consider that *more* consistent is better.


    But it is *less* consistent with respect to statement syntax. A clue
    from my statement above "It's a matter of what you choose to attach
    your need for consistency to."

    >> Maybe in the next round of changes they'll make everything consistent
    >> (nobody will mind rewriting again from what I can surmise). Then
    >> again, maybe the next round will only be a hodgepodge of changes like
    >> this one.

    >
    > I don't consider that making major changes to a language every version
    >is wise, but neither do I think that maintaining 100% compatibility with all
    >previous versions is wise.


    Maintaining compatibility unless there is a clear reason to change it
    should be the objective. You say I'm obtuse, but I don't know how to
    be any more clear than http://www.mvps.org/vb/tips/stability.htm

    >Well, more correctly, I think that there is a
    >place for nearly 100% backwords compatible languages,


    Right. Languages you intend to use for mission critical "legacy"
    applications. Languages you intend to build libraries of code with.

    >but clearly VB does
    >not attempt to fill that niche.


    Ya Think??!?! You get the "perceptive statement of the day" award.

    That's not what Microsoft told us before. VB was billed as a "real
    development environment" suitable for writing mission critical "new
    legacy" applications.

    They've broken that promise.

    It is *now* clear that Microsoft does not consider VB to be in that
    niche, I agree. That's why I've said that VB is suitable only for
    "throwaway code" applications. Prototyping and scripting.

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

  7. #22
    Patrick Troughton Guest

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


    Dan Barclay <Dan@MVPs.org> wrote:
    >On Thu, 8 Aug 2002 17:18:15 -0400, "Daniel Pratt"
    ><dprREMOVETHISatt71@hotmail.com> wrote:
    >
    >
    >Yea, what I posted was obtuse to folks that want to ignore it:


    No, you're just doing a poor job of explaining yourself. We're asking nicely
    for elaboration. Being rude isn't scoring you any points.

    >======================
    >So, now that we've established that it must be better to enclose
    >argument lists in parens in all cases,


    Just to be clear, my point was not that parens were better. My point was
    to compare VB6's 5 syntax rules (plus 2 special cases) for when to use parens
    around arguments versus VB.NET's 1 rule. There's a misperception among some
    people that VB.NET is somehow harder to learn than VB6. What I am trying
    to do is to educate people on the differences between the two languages.


    >should we now expect MS to
    >change the syntax on the remainder of statements so that they use
    >parens (yea, more like C).


    They've already done that. The syntax for calling routines in VB.NET is consistant
    AFAIK. Are you saying that you're aware of some exception to the rule? Maybe
    there is an exception...I don't know...but off the top of my head I can't
    think of one. Did you want us to keep playing this guessing game or will
    you just tell us?

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


    The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
    Example...

    Debug.Write("VB.NET is easy to learn and makes programming fun again!")

    BTW, there is no overloaded version of the Write method that accepts a boolean
    as the second parameter as your example shows. Are you trying to be funny?


    /Pat

  8. #23
    Dan Barclay Guest

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

    On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >>
    >>Yea, what I posted was obtuse to folks that want to ignore it:

    >
    >No, you're just doing a poor job of explaining yourself. We're asking nicely
    >for elaboration. Being rude isn't scoring you any points.
    >
    >>======================
    >>So, now that we've established that it must be better to enclose
    >>argument lists in parens in all cases,

    >
    >Just to be clear, my point was not that parens were better. My point was
    >to compare VB6's 5 syntax rules (plus 2 special cases) for when to use parens
    >around arguments versus VB.NET's 1 rule.


    >There's a misperception among some
    >people that VB.NET is somehow harder to learn than VB6. What I am trying
    >to do is to educate people on the differences between the two languages.


    I can't (and therefore won't) argue one way or the other about which
    is easier. My point regarding parens was that it adds consistency
    from one point of view, and reduces consistency from another point of
    view.

    If it makes it easier for you, so be it. However, the change didn't
    result in a net improvement, it only resulted in change. That being
    the case, the default position they should have taken on it would have
    been to leave it as it was.

    I'm not arguing that one way is better than the other...I'd say that
    even if it started out the other way. *Both* methods are inconsistent
    from one point of view or the other.

    >>should we now expect MS to
    >>change the syntax on the remainder of statements so that they use
    >>parens (yea, more like C).

    >
    >They've already done that. The syntax for calling routines in VB.NET is consistant
    >AFAIK. Are you saying that you're aware of some exception to the rule? Maybe
    >there is an exception...I don't know...but off the top of my head I can't
    >think of one. Did you want us to keep playing this guessing game or will
    >you just tell us?


    OK, try this. Go to VB.NetHelp|LanguageReference|Statements.

    Now, pick statements that take arguments and look at some examples
    (starting at the top of what I have):

    AddHandler Obj.Ev_Event, AddressOf EventHandler ' invisible parens!
    Erase Int3DArray, Int2DArray ' and again here. Cool!
    etc, etc.

    Oh, and here's a really cool one:

    Return "Infant"

    Do you see any parens around the arguments on those statements? Any?

    These statements don't require parens around the argument list (or did
    I misconstrue something here?). Yet, our own statements now require
    parens when they did not previously require them.

    How am I not being clear?

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

    >
    >The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
    >Example...
    >
    >Debug.Write("VB.NET is easy to learn and makes programming fun again!")
    >
    >BTW, there is no overloaded version of the Write method that accepts a boolean
    >as the second parameter as your example shows. Are you trying to be funny?


    My bad. I'd forgot that VB.Net didn't have the debug.print method.
    Using the old Print method allowed you to put whatever you wanted (and
    more than one) as arguments.

    The issue regards statements and the usage of parents around statement
    arguments. See above. To be consistent, I presume we need to now
    change the syntax of those statements to be more like:

    AddHandler (Obj.Ev_Event, AddressOf EventHandler)
    Erase (Int3DArray, Int2DArray)
    Return ("Infant")

    Dan (also waiting on End For)
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  9. #24
    Patrick Troughton Guest

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


    Hi Dan,

    I must say that I am dissappointed in you. You know as well as I do that
    AddressOf is an *operator* not a procedure. AddressOf is no different than
    +, *, - or Like. You don't require parens around after a plus sign or division
    sign, do you? And please, don't try to plead ignorance because AddressOf
    was an operator in VB6, too. That hasn't changed. The same goes for the rest
    of your points since none of them are procedures. I can't believe you tried
    that. You should know better.

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>>
    >>>Yea, what I posted was obtuse to folks that want to ignore it:

    >>
    >>No, you're just doing a poor job of explaining yourself. We're asking nicely
    >>for elaboration. Being rude isn't scoring you any points.
    >>
    >>>======================
    >>>So, now that we've established that it must be better to enclose
    >>>argument lists in parens in all cases,

    >>
    >>Just to be clear, my point was not that parens were better. My point was
    >>to compare VB6's 5 syntax rules (plus 2 special cases) for when to use

    parens
    >>around arguments versus VB.NET's 1 rule.

    >
    >>There's a misperception among some
    >>people that VB.NET is somehow harder to learn than VB6. What I am trying
    >>to do is to educate people on the differences between the two languages.

    >
    >I can't (and therefore won't) argue one way or the other about which
    >is easier. My point regarding parens was that it adds consistency
    >from one point of view, and reduces consistency from another point of
    >view.
    >
    >If it makes it easier for you, so be it. However, the change didn't
    >result in a net improvement, it only resulted in change. That being
    >the case, the default position they should have taken on it would have
    >been to leave it as it was.
    >
    >I'm not arguing that one way is better than the other...I'd say that
    >even if it started out the other way. *Both* methods are inconsistent
    >from one point of view or the other.
    >
    >>>should we now expect MS to
    >>>change the syntax on the remainder of statements so that they use
    >>>parens (yea, more like C).

    >>
    >>They've already done that. The syntax for calling routines in VB.NET is

    consistant
    >>AFAIK. Are you saying that you're aware of some exception to the rule?

    Maybe
    >>there is an exception...I don't know...but off the top of my head I can't
    >>think of one. Did you want us to keep playing this guessing game or will
    >>you just tell us?

    >
    >OK, try this. Go to VB.NetHelp|LanguageReference|Statements.
    >
    >Now, pick statements that take arguments and look at some examples
    >(starting at the top of what I have):
    >
    > AddHandler Obj.Ev_Event, AddressOf EventHandler ' invisible parens!
    >Erase Int3DArray, Int2DArray ' and again here. Cool!
    > etc, etc.
    >
    >Oh, and here's a really cool one:
    >
    > Return "Infant"
    >
    >Do you see any parens around the arguments on those statements? Any?
    >
    >These statements don't require parens around the argument list (or did
    >I misconstrue something here?). Yet, our own statements now require
    >parens when they did not previously require them.
    >
    >How am I not being clear?
    >
    >>
    >>> Debug.Print("This Change Makes Sense:",False)

    >>
    >>The syntax for using Debug *is* consistant with VB.NET's 1 rule standard.
    >>Example...
    >>
    >>Debug.Write("VB.NET is easy to learn and makes programming fun again!")
    >>
    >>BTW, there is no overloaded version of the Write method that accepts a

    boolean
    >>as the second parameter as your example shows. Are you trying to be funny?

    >
    >My bad. I'd forgot that VB.Net didn't have the debug.print method.
    >Using the old Print method allowed you to put whatever you wanted (and
    >more than one) as arguments.
    >
    >The issue regards statements and the usage of parents around statement
    >arguments. See above. To be consistent, I presume we need to now
    >change the syntax of those statements to be more like:
    >
    >AddHandler (Obj.Ev_Event, AddressOf EventHandler)
    >Erase (Int3DArray, Int2DArray)
    >Return ("Infant")
    >
    >Dan (also waiting on End For)
    >Language Stability is a *feature* I wish VB had!
    > (#6)
    >Error 51
    >Error 3
    >Error 9
    >....



  10. #25
    Frank Oquendo Guest

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

    Patrick Troughton had this to say:

    > I must say that I am dissappointed in you. You know as well as I do
    > that AddressOf is an *operator* not a procedure. AddressOf is no
    > different than +, *, - or Like. You don't require parens around after
    > a plus sign or division sign, do you? And please, don't try to plead
    > ignorance because AddressOf was an operator in VB6, too. That hasn't
    > changed. The same goes for the rest of your points since none of them
    > are procedures. I can't believe you tried that. You should know
    > better.


    AddHandler is a statement and it doesn't require any parens. Why is that?

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



  11. #26
    Mike Mitchell Guest

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

    On 8 Aug 2002 15:48:34 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >........ There's a misperception among some
    >people that VB.NET is somehow harder to learn than VB6.


    There's a misperception among some Eskimos that they don't need
    freezers. There's a misperception among some young, reckless drivers
    that driving while drunk and stoned won't get them killed. There's a
    misperception among lemmings that cliffs are the only way out.

    MM

  12. #27
    Mike Mitchell Guest

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

    On Thu, 08 Aug 2002 22:14:00 -0500, Dan Barclay <Dan@MVPs.org> wrote:

    >How am I not being clear?


    By not agreeing with him!

    MM

  13. #28
    Patrick Troughton Guest

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


    "Frank Oquendo" <nospam@please.com> wrote:
    >Patrick Troughton had this to say:
    >
    >
    >AddHandler is a statement and it doesn't require any parens. Why is that?
    >


    That answer is in the question. It's a statement, not a procedure.

    /Pat

  14. #29
    Daniel Pratt Guest

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

    Hi Frank,

    "Frank Oquendo" <nospam@please.com> wrote in message
    news:3d53379e@10.1.10.29...
    <snip>
    > AddHandler is a statement and it doesn't require any parens. Why is that?


    I think that it should, which is why I mentioned it as one of VB.NET's
    inconsistencies in a prior post. I (obviously) don't think that VB.NET
    doesn't have its own inconsistencies, but there are far less than in VB6. As
    I said before, more consistency is better.

    Regards,
    Dan



  15. #30
    Patrick Troughton Guest

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


    From the VB6 help files...

    <QUOTE>
    AddressOf Operator

    A unary operator that causes the address of the procedure it precedes to
    be passed to an API procedure that expects a function pointer at that position
    in the argument list.
    </QUOTE>

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >On 8 Aug 2002 20:23:55 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>
    >>Hi Dan,
    >>
    >>I must say that I am dissappointed in you. You know as well as I do that
    >>AddressOf is an *operator* not a procedure. AddressOf is no different than
    >>+, *, - or Like. You don't require parens around after a plus sign or division
    >>sign, do you? And please, don't try to plead ignorance because AddressOf
    >>was an operator in VB6, too. That hasn't changed.

    >
    >What the *heck* are you talking about. In what I quoted AddressOf was
    >used as an argument to the statement AddHandler. This was cut/pasted
    >directly from VB.Net help on that statement.
    >
    >The point, as clearly shown, is that VB statements (internal
    >procedures) do not require parens around their arguments... which is
    >inconsistent with user statements (for user procedures) that do.
    >
    >Perhaps Mr Pratt can explain this to you better.
    >
    >>The same goes for the rest
    >>of your points since none of them are procedures. I can't believe you tried
    >>that. You should know better.

    >
    >Each of those statements executes a built in procedure. The the
    >difference is who wrote the procedure.
    >
    >Dan
    >
    >Language Stability is a *feature* I wish VB had!
    > (#6)
    >Error 51
    >Error 3
    >Error 9
    >....



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