VB6 vs VB.NET...Procedure Calling Syntax

[Dan Barclay]

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

[Dan Barclay]

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

[Patrick Troughton]

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

[Patrick Troughton]

"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

[Dan Barclay]

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

[Dan Barclay]

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

[Patrick Troughton]

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

[Mike Mitchell]

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

[Patrick Troughton]

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

[Patrick Troughton]

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

[Mike Mitchell]

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

[Dan Barclay]

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

[Dan Barclay]

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

[Patrick Troughton]

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

[Patrick Troughton]

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