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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 6 FirstFirst 12345 ... LastLast
Results 31 to 45 of 79

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

  1. #31
    Dan Barclay Guest

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

    On Fri, 9 Aug 2002 08:24:49 -0400, "Daniel Pratt"
    <dprREMOVETHISatt71@hotmail.com> wrote:

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


    Can you *please* explain this to Pat. Slowly.

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

  2. #32
    Dan Barclay Guest

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

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

  3. #33
    Patrick Troughton Guest

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


    Dan Barclay <Dan@MVPs.org> wrote:
    >On Fri, 9 Aug 2002 08:24:49 -0400, "Daniel Pratt"
    >
    >Can you *please* explain this to Pat. Slowly.
    >


    As I pointed out earlier, the answer is in the question. AddHandler is a
    statement, not a procedure. You might want to take a look at the subject
    line of this thread, "VB6 vs VB.NET...Procedure Calling Syntax". Hint: ===>Procedure<===
    Calling Syntax

    Now, I'm not saying that there aren't any exceptions. Who knows? Maybe there
    are some that I haven't come across yet. Maybe if you did hard enough, you
    might come up with something. So far, you haven't shown an exception. But
    even if you do come up with one or even a couple, 99% consistancy is better
    than none.

    /Pat


  4. #34
    Patrick Troughton Guest

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


    "Patrick Troughton" <Patrick@Troughton.com> wrote:
    >
    >Maybe if you did hard enough, you
    >might come up with something.


    My bad...'did' should be 'dig'.

    /Pat

  5. #35
    Dan Barclay Guest

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

    Yes Patrick. AddressOf is an operator. When used in the following
    context:

    AddHandler Obj.Ev_Event, AddressOf EventHandler

    the term "AddressOf EventHandler" is commonly known as an argument for
    the statement AddHandler.

    As such, it is included in the argument list which is NOT contained in
    parenthesis. That is, of course, inconsistent... now that the changes
    to the language have made the same syntax for user generated
    statements require parenthesis.

    How about we just be consistent and require parenthesis here as well?

    AddHandler (Obj.Ev_Event, AddressOf EventHandler )

    You might as well just go ahead and clean this messy language up now
    that you've recognized a glitch (or do you still not recognize it?).

    Dan

    On 9 Aug 2002 13:07:33 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

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


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

  6. #36
    Dan Barclay Guest

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

    On 9 Aug 2002 13:24:00 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >
    >Dan Barclay <Dan@MVPs.org> wrote:
    >>On Fri, 9 Aug 2002 08:24:49 -0400, "Daniel Pratt"
    >>
    >>Can you *please* explain this to Pat. Slowly.
    >>

    >
    >As I pointed out earlier, the answer is in the question. AddHandler is a
    >statement, not a procedure.


    Do you think that AddHandler does NOT call a procedure? What the heck
    do you think it does then?

    >You might want to take a look at the subject
    >line of this thread, "VB6 vs VB.NET...Procedure Calling Syntax". Hint: ===>Procedure<===
    >Calling Syntax


    Yes, and you might want to look at the top message I posted explaining
    the "Call-less" syntax origin... which was to allow users to create
    their own statements.

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

  7. #37
    Patrick Troughton Guest

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


    We were talking about procedures, not statements. So you think there should
    parens around statements, too? OK, fine. Let's entertain your idea for a
    moment...

    Dim is a statement. Do you think there should be parens after Dim? How about
    Sub? That's a statement, too. What about the If...End If and Sub...End Sub
    statements? I guess you think they should all have parens. Is that what you're
    trying to tell us? I guess you won't be happy until VB looks like this...


    Public (Class (DanBarclay))
    Private (Const (MSG As (String)) = "Dan Barclay " & _
    ("has gone off his rocker!")

    Public (Sub (DisplayMessage()))
    MsgBox(MSG, MsgBoxStyle.Critical))
    End (Sub)
    End (Class)

    Yeah, that will be really easy for beginners to learn....

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >Yes Patrick. AddressOf is an operator. When used in the following
    >context:
    >
    > AddHandler Obj.Ev_Event, AddressOf EventHandler
    >
    >the term "AddressOf EventHandler" is commonly known as an argument for
    >the statement AddHandler.
    >
    >As such, it is included in the argument list which is NOT contained in
    >parenthesis. That is, of course, inconsistent... now that the changes
    >to the language have made the same syntax for user generated
    >statements require parenthesis.
    >
    >How about we just be consistent and require parenthesis here as well?
    >
    > AddHandler (Obj.Ev_Event, AddressOf EventHandler )
    >
    >You might as well just go ahead and clean this messy language up now
    >that you've recognized a glitch (or do you still not recognize it?).



  8. #38
    Mike Mitchell Guest

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

    On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >Dim is a statement. Do you think there should be parens after Dim? How about
    >Sub? That's a statement, too. What about the If...End If and Sub...End Sub
    >statements? I guess you think they should all have parens. Is that what you're
    >trying to tell us? I guess you won't be happy until VB looks like this...


    Words like...hole...digging...stop come to mind here.

    MM

  9. #39
    Patrick Troughton Guest

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


    That's exactly my point. Apparently Dan thinks we should apply procecure calling
    syntax to non-procedures as well. Not a pretty sight, is it?

    /Pat

    kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
    >On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>Dim is a statement. Do you think there should be parens after Dim? How

    about
    >>Sub? That's a statement, too. What about the If...End If and Sub...End

    Sub
    >>statements? I guess you think they should all have parens. Is that what

    you're
    >>trying to tell us? I guess you won't be happy until VB looks like this...

    >
    >Words like...hole...digging...stop come to mind here.
    >
    >MM



  10. #40
    Patrick Troughton Guest

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


    I understood your point. It didn't apply. Adding parens around statements
    was Dan's idea, not mine. I think it's a dumb idea if you ask me. I was trying
    to be sarcastic. Sorry, next time I'll try to be more clear.

    /Pat

    kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
    >On 10 Aug 2002 05:38:43 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >No, you missed my point. I was applying it to you!
    >
    >MM



  11. #41
    Mike Mitchell Guest

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

    On 10 Aug 2002 05:38:43 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >That's exactly my point. Apparently Dan thinks we should apply procecure calling
    >syntax to non-procedures as well. Not a pretty sight, is it?


    No, you missed my point. I was applying it to you!

    MM

  12. #42
    Dan Barclay Guest

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

    On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >
    >We were talking about procedures, not statements.


    Again (again) I refer you to my top level message here:

    "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?"

    >So you think there should
    >parens around statements, too? OK, fine.


    I leave that for those that argue for consistency. Hmmmm.... I
    though that was you!

    >Let's entertain your idea for a
    >moment...
    >
    >Dim is a statement. Do you think there should be parens after Dim? How about
    >Sub? That's a statement, too. What about the If...End If and Sub...End Sub
    >statements? I guess you think they should all have parens. Is that what you're
    >trying to tell us? I guess you won't be happy until VB looks like this...
    >
    >
    >Public (Class (DanBarclay))
    > Private (Const (MSG As (String)) = "Dan Barclay " & _
    > ("has gone off his rocker!")
    >
    > Public (Sub (DisplayMessage()))
    > MsgBox(MSG, MsgBoxStyle.Critical))
    > End (Sub)
    >End (Class)
    >
    >Yeah, that will be really easy for beginners to learn....


    For once we're in agreement. I think that makes no more sense than
    trying to force ill conceived "consistency" between the Call syntax
    and statement syntax.

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

  13. #43
    Dan Barclay Guest

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

    On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

    >We were talking about procedures, not statements.


    I asked you a question you apparently "overlooked" earlier so I'll
    pull it out into a message of its own:

    ===================
    >As I pointed out earlier, the answer is in the question. AddHandler is a
    >statement, not a procedure.


    Do you think that AddHandler does NOT call a procedure? What the heck
    do you think it does then?

    ====================

    Now, given the case that you can find some statement that's not a
    procedure (though even a declaration is actually a procedure under the
    hood), perhaps you can explain how the "procedure executing statement"
    like AddHandle (and friends) should be handled. Shouldn't they be
    handled consistently with other "procedure executing statements" that
    a user writes?

    If you want to preach consistency, follow your preaching and see where
    it leads you.

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

  14. #44
    Patrick Troughton Guest

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


    You might think that quoting yourself somehow backs you up but you have zero
    credibility in my book. You've consistently failed to show that you have
    even the slightest inkling of understanding of how the Visual Basic language
    works. Let me spell it out for you *again*... procedures and statements are
    not the same thing. They weren't in VB6. They're not in VB.NET. It's no wonder
    you're so confused about VB.NET. Obviously, you don't understand VB6 either.

    Now you may prefer to think of statements and procedures as being the same
    thing, but they're not. If you ever bothered reading the Visual Basic documentation
    you should know this. So as soon as you get some free time, may I suggest
    that you begin here....

    Visual Basic Language Concepts - Procedures
    ms-help://MS.VSCC/MS.MSDNVS/vbcn7/html/vbconIntroductionToProcedures.htm

    Visual Basic Language Concepts - Statements
    ms-help://MS.VSCC/MS.MSDNVS/vbcn7/html/vaconstatementsoverview.htm

    And note that they're in two different sections (hint...hint...hint). But
    knowing you, you probably won't bother. Why should you need to read the documention?
    Obviously, you already know everything....

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>
    >>We were talking about procedures, not statements.

    >
    >Again (again) I refer you to my top level message here:
    >
    >"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?"



  15. #45
    Patrick Troughton Guest

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


    I didn't overlook it. I addressed it head on. AddHandler is a statement, not
    a procedure. Whether a statement calls excutable code behind the scenes is
    irrelevent. Again, I refer you to the If...End If statement. How do you think
    an If statement works if not by calling executable code? Hint...it's called
    a branch.

    /Pat

    Dan Barclay <Dan@MVPs.org> wrote:
    >On 9 Aug 2002 15:39:07 -0700, "Patrick Troughton"
    ><Patrick@Troughton.com> wrote:
    >
    >>We were talking about procedures, not statements.

    >
    >I asked you a question you apparently "overlooked" earlier so I'll
    >pull it out into a message of its own:
    >
    >===================
    >>As I pointed out earlier, the answer is in the question. AddHandler is

    a
    >>statement, not a procedure.

    >
    >Do you think that AddHandler does NOT call a procedure? What the heck
    >do you think it does then?
    >
    >====================
    >
    >Now, given the case that you can find some statement that's not a
    >procedure (though even a declaration is actually a procedure under the
    >hood), perhaps you can explain how the "procedure executing statement"
    >like AddHandle (and friends) should be handled. Shouldn't they be
    >handled consistently with other "procedure executing statements" that
    >a user writes?
    >
    >If you want to preach consistency, follow your preaching and see where
    >it leads you.
    >
    >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