VB6 vs VB.NET...Procedure Calling Syntax

[Larry Serflaten]

"Dan Barclay" <Dan@MVPs.org> wrote

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

It is a declaration statement, just like Event, Sub, Function, Dim, Const, et. al.

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

Regaurdless of whether the reduction in rules constitues consistancy, it does
promote a reduction in hard to find errors. That is more than likey one of the
main reasons for the change.

LFS

[Dan Barclay]

Larry,

On Sat, 10 Aug 2002 17:31:31 -0500, "Larry Serflaten"
<serflaten@usinternet.com> wrote:

>"Dan Barclay" <Dan@MVPs.org> wrote
>
>> Do you think that AddHandler does NOT call a procedure? What the heck
>> do you think it does then?
>
>It is a declaration statement, just like Event, Sub, Function, Dim, Const, et. al.

You know, I'm not supposed to be the .Net expert here but I think
maybe you'd better take a look at what AddHandler does. It's a
*procedure* that adds the address of another procedure to an execution
list. It is done dynamically, not as a static declaration.

What's more, you can remove it from the list with RemoveHandler.

But, maybe you don't call execution processes procedures these days.
That' up to you.

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

[Dan Barclay]

On 10 Aug 2002 14:44:13 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

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

OK, Patrick, let's look at it from the opposite direction.

If you *don't* believe they used the initial syntax to allow users to
"create their own statements" and to be consistent with the syntax of
built-in statements then why do you think they used that syntax?

Do you think they did it out of plain stupidity? Do you think they
did it because it was easier (hint: they already had code to handle
Call using parens)? Why did they do it?

You can believe me or not believe me. I was there when it was
introduced and I do remember.

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

VB6? Hmmm... I think they introduced this around QuickBasic 2.0, but
I could be wrong.

>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

Yes, perhaps you missed this statement: "Executable statements, which
initiate actions. These statements can execute a method or function,
and they can loop or branch through blocks of code..."

So, executable statements created by the user are handled differently
than built-in executable statements? Do you really contend they are
different?

Perhaps you'd like to explain that MsgBox isn't a procedure or
function?

MsgBox "Prompt",0,"title"
Response=MsgBox("Prompt",0,"title")

Do you really believe they have different code handling the function
in those two lines?

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

Perhaps you should read it yourself?

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

[Larry Serflaten]

"Dan Barclay" <Dan@MVPs.org> wrote
> >
> >It is a declaration statement, just like Event, Sub, Function, Dim, Const, et. al.
>
> You know, I'm not supposed to be the .Net expert here but I think
> maybe you'd better take a look at what AddHandler does. It's a
> *procedure* that adds the address of another procedure to an execution
> list. It is done dynamically, not as a static declaration.
>
> What's more, you can remove it from the list with RemoveHandler.
>
> But, maybe you don't call execution processes procedures these days.
> That' up to you.

That's right, ReDim is an executable statement as well, but it would still be
grouped in with all the other declarations. The fact that it is an executable
statement does not preclude it from belonging to the group containing all the
other declaration statements.

AddHandler is the runtime equivilent of the Handles keyword. Just like
ReDim is the runtime equivilent of the Dim keyword. Certainly you can
not say that Handles is some procedure as well? Because it is a declaration
it would not use parentheses as all the other procedures do.

You can make up your own 'story' about why it doesn't follow the rules,
but in the final analysis, it is MS who decides how it should be represented,
and used. According to their documentation, AddHandler is in the same
group as all the other declarations:

http://msdn.microsoft.com/library/en...sConstants.asp

They treat it as the declaration statement for use in declaring Events.

LFS

[Larry Serflaten]

"Larry Serflaten" <serflaten@usinternet.com> wrote
>
> They treat it as the declaration statement for use in declaring Events.

Perhaps a bad choice of words, its purpose is to 'declare' which procedure
is going to handle whatever event. MS uses the word 'associate' which is
probably more descriptive, since events are actually 'declared' using another
means....

LFS

[Dan Barclay]

On 10 Aug 2002 14:44:13 -0700, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

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

OK, Larry, I went back and found some doc on it so maybe you'll be
happy. Again (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?"

But I also refer you to the QB4 manual:

=====quote======
A SUB procedure differs from a FUNCTION procedure in that a SUB cannot
be called by using its name within an expression. A call to a SUB is
a stand-alone statement, like BASIC's CIRCLE statement.
=====endquote===

What part of "is a stand-alone statement" do you not understand???

What part of "like BASIC's CIRCLE statement" do you not understand?

Continuing:

=====quote======
You can call a SUB in one of the following two ways:

1. Put its name in a CALL statement:

CALL PrintMessage

2. Use its name as a statement itself:

PrintMessage

=====endquote===

I (again) ask: " what part of 'as a statement itself' do you not
understand?"

I was wrong about one thing, though. The Call-less syntax (user
defined statement) was not introduced with QuickBasic 2. I just tried
it and it doesn't work in that version. It was introduced with either
3.x or 4.0.

It still leaves the issue that now user defined executable statements
have a different syntax than system defined executable statements.

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

[Dan Barclay]

On Sun, 11 Aug 2002 01:04:41 -0500, Dan Barclay <Dan@MVPs.org> wrote:

>OK, Larry,

Sorry for any confusion, Larry... this was in response to Patrick's
statements.

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

[Larry Serflaten]

"Dan Barclay" <Dan@MVPs.org> wrote in message >
> "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?"
>
> But I also refer you to the QB4 manual:
>
> =====quote======
> A SUB procedure differs from a FUNCTION procedure in that a SUB cannot
> be called by using its name within an expression. A call to a SUB is
> a stand-alone statement, like BASIC's CIRCLE statement.
> =====endquote===


You seem to be arguing that you call user executable statements, just like
VB's system executable statements. I get that from your last comment:


> It still leaves the issue that now user defined executable statements
> have a different syntax than system defined executable statements.

But since you brought it up, can you create an executable statement like
CIRCLE that seems to attach itself to a few objects, but never shows up
in the object browser for those objects? What's that, VB does have a few
system methods that are called differently than what you can create? Why
then is it an issue for VB.Net? You know the ones I mean, Circle, Line,
and Print.

And its not just these.

Show me how you would create a user executable command that acts just
like Date and Time. One minute its a function, and the next a property!
What's that? You can't do that? Then why is it an issue for VB.Net?

And its not just those.

If VB allows you to 'extend' the environment and call on them just like
its own commands, show me how you would create routines that act like
the Error keyword. One minute its a Function, complete with parentheses
and a parameter, and the next its a sub, with one parameter and no parens.
I know you can call it that way, but how do you get it to perform two different
tasks based on how it was called? What's that? You can't do that with VB?
Then why is such differences an issue in .Net?

When you've tired yourself out on that one, have a look at Input, Seek, and Mid
also....

As I said before, IMO one advantage of using the parentheses is to help reduce the
occurances of hard to find bugs, and that is in addition to being a *more consistant*
format than VB6 allowed.

LFS

[Patrick Troughton]

QuickBasic 2.0?? No wonder you're so lost. In case you haven't noticed, this
is a Visual Basic newsgroup. You want to take this from a differient direction?
Fine....let's do exactly that. Directly from the Visual Basic documentation.....

<quote>
AddHandler Statement

See Also
RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
and RemoveHandler

Associates an event with an event handler.
</quote>

Can you please read the second word above, immediately after AddHandler?
Hint...this word is spelled S T A T E M E N T.

/Pat

Dan Barclay <Dan@MVPs.org> wrote:
>On 10 Aug 2002 14:44:13 -0700, "Patrick Troughton"
><Patrick@Troughton.com> wrote:
>
>>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.
>
>OK, Patrick, let's look at it from the opposite direction.

[MMFAN]

As usual, you twist and manipulate the argument in your favor when you
have clearly lost. Just give it up!

Patrick Troughton wrote:
> QuickBasic 2.0?? No wonder you're so lost. In case you haven't noticed, this
> is a Visual Basic newsgroup. You want to take this from a differient direction?
> Fine....let's do exactly that. Directly from the Visual Basic documentation.....
>
> <quote>
> AddHandler Statement
>
> See Also
> RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
> and RemoveHandler
>
> Associates an event with an event handler.
> </quote>
>
> Can you please read the second word above, immediately after AddHandler?
> Hint...this word is spelled S T A T E M E N T.
>
> /Pat
>
> Dan Barclay <Dan@MVPs.org> wrote:
>
>>On 10 Aug 2002 14:44:13 -0700, "Patrick Troughton"
>><Patrick@Troughton.com> wrote:
>>
>>
>>>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.
>>
>>OK, Patrick, let's look at it from the opposite direction.
>
>

[Daniel Pratt]

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:11sblukf6j3b8g8cosv6evr9agah9mcrue@4ax.com...
<snip>
> You know, I'm not supposed to be the .Net expert here but I think
> maybe you'd better take a look at what AddHandler does. It's a
> *procedure* that adds the address of another procedure to an execution
> list. It is done dynamically, not as a static declaration.
>
> What's more, you can remove it from the list with RemoveHandler.
>
> But, maybe you don't call execution processes procedures these days.
> That' up to you.

I agree. If it walks like a duck...

Regards,
Dan

[Patrick Troughton]

There are two categories of statements in Visual Basic, declaration statemtens
and executable statements. This is from the Visual Basic documentation....

<quote>
A statement in Visual Basic is a complete instruction that can contain keywords,
operators, variables, constants, and expressions. All statements fall into
one of two categories: declaration statements, which name a variable, constant,
or procedure and can also specify a data type; or executable statements,
which initiate actions.
</quote>

ms-help://MS.VSCC/MS.MSDNVS/vbcn7/html/vaconWritingVBStatements.htm

So the fact that a statement runs executable code behind the scenes is irrelevent.
In fact, that's part of the very *definition* of what VB is. Other examples
of statements that run executable code are If...End If and For...Next loops.
If you don't want to take my word for it, that's fine. Here's what the Visual
Basic documentation says...

<quote>
An executable statement initiates action by executing a method. It can loop
or branch through blocks of code. Executable statements often contain mathematical
or conditional operators.

The following example uses an If...Then...Else statement to execute different
blocks of code based on the value of a variable. Within each block of code,
a For...Next statement causes a loop to be executed a specified number of
times.

Public Sub StartWidget(aWidget As Widget, clockwise As Boolean, _
revolutions As Integer)
Dim counter As Integer
If clockwise = True Then
For counter = 1 to revolutions
aWidget.SpinClockwise
Next counter
Else
For counter = 1 to revolutions
aWidget.SpinCounterClockwise
Next counter
End If
End Sub
The If...Then...Else statement in the example checks the value of the variable
clockwise. If the value is True, the SpinClockwise method of aWidget is invoked.
If the value is False, then the SpinCounterClockwise method of aWidget is
invoked. If...Then...Else statements end with End If.
</quote>

What's more, this is no different than VB6.

/Pat

"Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote:
>
>"Dan Barclay" <Dan@MVPs.org> wrote in message
>news:11sblukf6j3b8g8cosv6evr9agah9mcrue@4ax.com...
><snip>
>> You know, I'm not supposed to be the .Net expert here but I think
>> maybe you'd better take a look at what AddHandler does. It's a
>> *procedure* that adds the address of another procedure to an execution
>> list. It is done dynamically, not as a static declaration.
>>
>> What's more, you can remove it from the list with RemoveHandler.
>>
>> But, maybe you don't call execution processes procedures these days.
>> That' up to you.
>
> I agree. If it walks like a duck...
>
>Regards,
>Dan
>
>

[Patrick Troughton]

Come on, Dan. You keep avoiding the issues. Whether a statement calls excutable
code behind the scenes is irrelevent. How do you think an If statement works
if not by calling executable code?

/Pat

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>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

[Patrick Troughton]

Come on Dan, you keep avoiding the issues. Directly from the Visual Basic
documentation.....

<quote>
AddHandler Statement

See Also
RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
and RemoveHandler

Associates an event with an event handler.
</quote>

Please tell me what the second word is above, immediately after AddHandler?

/Pat

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>Directly from the Visual Basic documentation.....
>
><quote>
>AddHandler Statement
>
>See Also
>RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
>and RemoveHandler
>
>Associates an event with an event handler.
></quote>
>
>Can you please read the second word above, immediately after AddHandler?
>Hint...this word is spelled S T A T E M E N T.
>

[MMFAN]

You're the one who is missing the point. Do your work reread his posts.
Don't be lazy!

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>Come on Dan, you keep avoiding the issues. Directly from the Visual Basic
>documentation.....
>
><quote>
>AddHandler Statement
>
>See Also
>RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
>and RemoveHandler
>
>Associates an event with an event handler.
></quote>
>
>Please tell me what the second word is above, immediately after AddHandler?
>
>/Pat
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote:
>>
>>Directly from the Visual Basic documentation.....
>>
>><quote>
>>AddHandler Statement
>>
>>See Also
>>RemoveHandler Statement | Handles | Events and Event Handlers | AddHandler
>>and RemoveHandler
>>
>>Associates an event with an event handler.
>></quote>
>>
>>Can you please read the second word above, immediately after AddHandler?
>>Hint...this word is spelled S T A T E M E N T.
>>
>