Are event arguments needed for button control

[Dean Slindee]

When you drop a button on a form, a Click event is created by the designer.
Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal e
As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

Thanks,
Dean S

[rowe_newsgroups]

On Jul 17, 8:49*pm, "Dean Slindee" <[e-mail]:

When you drop a button on a form, a Click event is created by the designer.
Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal e
As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

Thanks,
Dean S

Try it and find out. There is no better way of learning.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

[Phill W.]

Dean Slindee wrote:

When you drop a button on a form, a Click event is created by the
designer. Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal
e As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

First guess - it wouldn't compile.
(actually VB'2008 might do some "clever" stuff; haven't got there yet)

VB wires up events using "delegates" and delegates are just methods with
a particular signature. If you don't supply the right arguments
(signature) for a method, VB can't wire up the event to that method (the
error is something like "method X cannot handle event Y").

I'm guessing that, like me, you're a VB "proper" Developer and I can see
what you're thinking - /why/ do you need these extraneous arguments?

Indeed, in the case you cite, there's not a lot of point but there's two
things to bear in mind:

(1) Other events /do/ use meaningful Event Argument classes, not just
the base class, EventArgs - take a look at, say, the Layout event; that
supplies your event handler with lots of useful stuff.

(2) Under VB "Proper" if you wrote six buttons, you'd get six *_Click
routines (ignoring Control Arrays). In VB.Net, you can have a /single/
method handling the click event of /many/ buttons, as in:

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click _
, btn5_Click _
, btn10_Click _
, btn15_Click _
, ... and so on ...

So how does this routine know /which/ button you actually clicked on?
That's what "sender" argument is for - you get an object reference to
the control (here, a button) that raised the event, as in

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click, ...

If ( TypeOf sender Is Button ) Then
MessageBox.Show( "You clicked " _
& DirectCast( sender, Button ).Name _
)
End If

End Sub

HTH,
Phill W.

[Just_a_fan]

The worst is that afterwards, double clicking on the control does not go
to the code any more.

Mike

On Fri, 18 Jul 2008 13:53:08 +0100, in
microsoft.public.dotnet.languages.vb "Phill W."
<p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote:

>Dean Slindee wrote:

>When you drop a button on a form, a Click event is created by the
designer. Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal
e As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

First guess - it wouldn't compile.
(actually VB'2008 might do some "clever" stuff; haven't got there yet)

VB wires up events using "delegates" and delegates are just methods with
a particular signature. If you don't supply the right arguments
(signature) for a method, VB can't wire up the event to that method (the
error is something like "method X cannot handle event Y").

I'm guessing that, like me, you're a VB "proper" Developer and I can see
what you're thinking - /why/ do you need these extraneous arguments?

Indeed, in the case you cite, there's not a lot of point but there's two
things to bear in mind:

(1) Other events /do/ use meaningful Event Argument classes, not just
the base class, EventArgs - take a look at, say, the Layout event; that
supplies your event handler with lots of useful stuff.

(2) Under VB "Proper" if you wrote six buttons, you'd get six *_Click
routines (ignoring Control Arrays). In VB.Net, you can have a /single/
method handling the click event of /many/ buttons, as in:

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click _
, btn5_Click _
, btn10_Click _
, btn15_Click _
, ... and so on ...

So how does this routine know /which/ button you actually clicked on?
That's what "sender" argument is for - you get an object reference to
the control (here, a button) that raised the event, as in

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click, ...

If ( TypeOf sender Is Button ) Then
MessageBox.Show( "You clicked " _
& DirectCast( sender, Button ).Name _
)
End If

End Sub

HTH,
Phill W.

[kimiraikkonen]

On Jul 18, 3:49 am, "Dean Slindee" <[e-mail]:

When you drop a button on a form, a Click event is created by the designer.
Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal e
As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

Thanks,
Dean S

Hi,
Simply, it wouldn't compile because it's expected that your button's
method(default button1_click) requires the same signature of "click"
event's , that is, "ByVal sender As System.Object, ByVal e As
System.EventArgs".

Thanks,

Onur Güzel

[Just_a_fan]

In opposition to what someone posted, it WILL run just find. But you
can't double click you way to the code any more.

As with all these kind of questions, trying it is the best way to find
out.

Mike
On Sat, 19 Jul 2008 02:19:09 -0700, in
microsoft.public.dotnet.languages.vb Ju********@home.net wrote:

>The worst is that afterwards, double clicking on the control does not go
to the code any more.

Mike

On Fri, 18 Jul 2008 13:53:08 +0100, in
microsoft.public.dotnet.languages.vb "Phill W."
<p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote:

>>Dean Slindee wrote:

>>When you drop a button on a form, a Click event is created by the
designer. Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal
e As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

First guess - it wouldn't compile.
(actually VB'2008 might do some "clever" stuff; haven't got there yet)

VB wires up events using "delegates" and delegates are just methods with
a particular signature. If you don't supply the right arguments
(signature) for a method, VB can't wire up the event to that method (the
error is something like "method X cannot handle event Y").

I'm guessing that, like me, you're a VB "proper" Developer and I can see
what you're thinking - /why/ do you need these extraneous arguments?

Indeed, in the case you cite, there's not a lot of point but there's two
things to bear in mind:

(1) Other events /do/ use meaningful Event Argument classes, not just
the base class, EventArgs - take a look at, say, the Layout event; that
supplies your event handler with lots of useful stuff.

(2) Under VB "Proper" if you wrote six buttons, you'd get six *_Click
routines (ignoring Control Arrays). In VB.Net, you can have a /single/
method handling the click event of /many/ buttons, as in:

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click _
, btn5_Click _
, btn10_Click _
, btn15_Click _
, ... and so on ...

So how does this routine know /which/ button you actually clicked on?
That's what "sender" argument is for - you get an object reference to
the control (here, a button) that raised the event, as in

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click, ...

If ( TypeOf sender Is Button ) Then
MessageBox.Show( "You clicked " _
& DirectCast( sender, Button ).Name _
)
End If

End Sub

HTH,
Phill W.

[Dean Slindee]

The reason for asking was that the event did compile in VS2008 after the
arguments were removed.
Thanks so much for your excellent answer.

"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote in message
news:g5**********@south.jnrs.ja.net...

Dean Slindee wrote:

>When you drop a button on a form, a Click event is created by the
designer. Within the Click event certain event parameters are defined:
Private Sub btnInsert_ButtonPressed(ByVal sender As System.Object, ByVal
e As System.EventArgs)

What harm or limitations would ensue if (ByVal sender As System.Object,
ByVal e As System.EventArgs) were changed to ().

First guess - it wouldn't compile.
(actually VB'2008 might do some "clever" stuff; haven't got there yet)

VB wires up events using "delegates" and delegates are just methods with a
particular signature. If you don't supply the right arguments (signature)
for a method, VB can't wire up the event to that method (the error is
something like "method X cannot handle event Y").

I'm guessing that, like me, you're a VB "proper" Developer and I can see
what you're thinking - /why/ do you need these extraneous arguments?

Indeed, in the case you cite, there's not a lot of point but there's two
things to bear in mind:

(1) Other events /do/ use meaningful Event Argument classes, not just the
base class, EventArgs - take a look at, say, the Layout event; that
supplies your event handler with lots of useful stuff.

(2) Under VB "Proper" if you wrote six buttons, you'd get six *_Click
routines (ignoring Control Arrays). In VB.Net, you can have a /single/
method handling the click event of /many/ buttons, as in:

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click _
, btn5_Click _
, btn10_Click _
, btn15_Click _
, ... and so on ...

So how does this routine know /which/ button you actually clicked on?
That's what "sender" argument is for - you get an object reference to the
control (here, a button) that raised the event, as in

Private Sub AnyButton_Click( ... ) _
Handles btnInsert.Click, ...

If ( TypeOf sender Is Button ) Then
MessageBox.Show( "You clicked " _
& DirectCast( sender, Button ).Name _
)
End If

End Sub

HTH,
Phill W.