What are these params

[Jay]

Everywhere I go (read/browse) I see these parameters....
ByVal sender As Object, ByVal e As System.EventArgs
Yet I never see them used within the function/method.

Could someone tell me what they mean/do please.

JP

[Jay B. Harlow [MVP - Outlook]]

Jay,
It is the .NET standard Event Pattern.

The 'sender' object is the object that raised the event. If you have a
single event handler handling multiple items, you can cast the 'sender'
object to the specific type & access the specific object raising the event.

Remember using either AddHandler & RemoveHandler or the Handles keyword you
can have a single Event Handler handle one or more events from one or more
objects.

The 'e' EventArgs is any event parameters. When you are defining your own
event you derive from EventArgs and include any addition information in your
derived class. Such as CancelEventArgs and MouseEventArgs. If there are no
parameters you normally pass EventArgs.Empty, incase a derived class decides
to pass a class derived from EventArgs to that handler.

For details see:
http://msdn.microsoft.com/library/de...guidelines.asp

http://msdn.microsoft.com/library/de...guidelines.asp

Hope this helps
Jay

"Jay" <qpr@*spamfree*xtra.co.nz> wrote in message
news:us**************@TK2MSFTNGP12.phx.gbl...

Everywhere I go (read/browse) I see these parameters....
ByVal sender As Object, ByVal e As System.EventArgs
Yet I never see them used within the function/method.

Could someone tell me what they mean/do please.

JP

[Fergus Cooney]

Hi Jay,

I answered a query a while back about event handlers. It also talked about
'sender' and 'e'. I'm including the whole thing here, so bear with me - your
answer is (mostly?) in there somewhere.

Regards,
Fergus

<post>
1 Private Sub TextBox1_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress
5 If e.KeyChar.IsNumber(e.KeyChar) Then
6 e.Handled = False
7 Else
8 e.Handled = True
9 End If
10 End Sub

When an event, like receiving a key press or a mouse action, occurs to a
Control, in this case a TextBox, a message is sent to the Control to inform it
about what's happened. All events that happen to Controls are handled by
built-in code but there is also the option for the <user> of the Control to
take some additional action. In your case it's discarding non-digit
keystrokes. Finally, the Control may trigger an event <itself> specifically
for the user. Dealing with events, ie. handling them, is optional.

You can hook into an event by installing what's called an Event Handler.
This is a routine which takes a particular form as shown by lines 1 to 4. The
'Handles' keyword tells the compiler that this Sub will handle events 'raised'
by the following Control and for the given event. In this case it's TextBox1
and the KeyPress event.

Note that this is a list and you can have more Controls, eg:
1 Private Sub AllMyTextBoxes_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress, TextBox2.KeyPress, _
5 txtAddressA.KeyPress, txtAddressB.KeyPress, etc

The name used in line 1 is completely arbitrary but the convention is to
have the Control name, an underscore and then the event name.

The arguments to an event handler are predefined.

'sender' is the Control to which the event happened and is an Object. This
is so that the same mechanism can be applied to any Object that can raise an
Event. I don't like the name myself. I never think in terms of a Control or
Object 'sending' an event. That, to me, is practically meaningless. I would
prefer VB to insert 'TheTextBox' or some name tailored to the Control or
Object. Ah, well.

'e' is another stupid name. It's a shorthand for EventArgs but it's
brevity goes against one of the key style principles of .NET, namely, long
names for better understanding*. e is always an object containing information
about the Event. In the case of a KeyPress, it will be KeyChar - the key that
was pressed and Handled, a variable, the setting of which, allows you to
discard the keystroke. (Empty and GetType() are the other two, which I will
ignore). [* However, saying that, I like g for Graphics! :-)]

Hooking into an Event.

This is done for you when you double-click a Form or Control, although it
only works for the default event. VB will write the outline of the required
Sub. You can get the other events for a Control by going into the top-left box
above the code for the form (I don't know what the box is called but it
usually shows the Form name) and selecting (Base Class Events). This will
put - in the <top-right> box - the events that your control can handle. Click
on the one you want and <that> event's Sub will be writen for you. Finally, if
you know what you are doing, you can simply type it in.

[If you ever get into C#, hooking into events take a bit more effort and
thereby teaches you the mechanism a bit better. You'll learn the same when you
get into Delegates in VB.]

Ok, that's Events 101. Keep asking. We'll get you there! :-)

Regards,
Fergus
</post>

[Fergus Cooney]

Hi again, Jay,

Part II.

As you'll have gathered by now, 'sender' and 'e' are the standard pattern
for passing information to an event handler. The pattern has to be upheld, but
not necessarily utilised.

Thus a MouseDown event handler may do something useful without needing to
care which mouse buttons has been pressed or where the mouse is. The
mouse-downness is sufficient and 'e' can be ignored.

Similarly, because event handlers generally handle an event for a specific
control (as reflected in the name) 'sender' can be ignored as well. The
Control can be accessed directly.

Consider
Sub Button1_Click (ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles Button1.Click
Button1.Enabled = False
SetHourglass
DoSomethingLongRunning
ResetHourglass
Button1.Enabled = True
End Sub

In this instance, sender has the same value as Button1. and using sender
would require
DirectCast (sender, Button).Enabled = False
which is clearly less clear

Consider, however,
Sub Button1_Click (ByVal sender As Object, _
ByVal e As System.EventArgs) _
* Handles Button1.Click, Button2.Click

* Dim TheButton As Button = DirectCast (sender, Button)
* TheButton.Enabled = False
SetHourglass
* DoSomethingLongRunning (TheButton.Text)
ResetHourglass
* TheButton.Enabled = True
End Sub

In this instance, sender is either Button1 or Button2 and needs to be
used.

Regards,
Fergus

[I still don't like the word 'sender' and I <hate> that it defaults to lower
case, moan, moan]

[Jay]

Big thanks to you both!

Jay

"Fergus Cooney" <fi******@tesco.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hi again, Jay,

Part II.

As you'll have gathered by now, 'sender' and 'e' are the standard pattern for passing information to an event handler. The pattern has to be upheld, but not necessarily utilised.

Thus a MouseDown event handler may do something useful without needing to care which mouse buttons has been pressed or where the mouse is. The
mouse-downness is sufficient and 'e' can be ignored.

Similarly, because event handlers generally handle an event for a specific control (as reflected in the name) 'sender' can be ignored as well. The
Control can be accessed directly.

Consider
Sub Button1_Click (ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles Button1.Click
Button1.Enabled = False
SetHourglass
DoSomethingLongRunning
ResetHourglass
Button1.Enabled = True
End Sub

In this instance, sender has the same value as Button1. and using sender would require
DirectCast (sender, Button).Enabled = False
which is clearly less clear

Consider, however,
Sub Button1_Click (ByVal sender As Object, _
ByVal e As System.EventArgs) _
* Handles Button1.Click, Button2.Click

* Dim TheButton As Button = DirectCast (sender, Button)
* TheButton.Enabled = False
SetHourglass
* DoSomethingLongRunning (TheButton.Text)
ResetHourglass
* TheButton.Enabled = True
End Sub

In this instance, sender is either Button1 or Button2 and needs to be used.

Regards,
Fergus

[I still don't like the word 'sender' and I <hate> that it defaults to lower case, moan, moan]

[Jay B. Harlow [MVP - Outlook]]

Fergus,

'sender' is the Control to which the event happened and is an Object. This is so that the same mechanism can be applied to any Object that can raise an Event. I don't like the name myself. I never think in terms of a Control or Object 'sending' an event. That, to me, is practically meaningless. I would prefer VB to insert 'TheTextBox' or some name tailored to the Control or
Object. Ah, well. Interesting thought. What happens in the case where I have MenuItem.Click,
ToolBarButton.Click, Button.Click and Form.Close all being handled by the
same event handler? :-)

I normally give 'theTextBox' or just 'textbox' when I cast 'sender' to the
specific type.

Normally VB.NET takes the name for the parameters to the event handler sub
from the parameters for the Delegate that defines the Event.

Remember events are actually defined in terms of a Delegate, for example the
MenuItem.Click event is defined as:

Public Delegate EventHandler(ByVal sender As Object, ByVal e As
EventArgs)

Public Class MenuItem

Public Event Click As EventHandler

End Class

Note that the EventHandler delegate is used by a significant number of
events. Which enable having only one Delegate class defined, rather than
having a significant number of Delegate Classes... (code reuse). Hence the
very generic names for the parameters.

When you define an event in VB.NET as:

Public Event NotifyUser(ByVal sender As Object, ByVal e As EventArgs)

Under the covers VB.NET is defining a NotifyUserEventHandler Delegate, such
as:

Public Delegate NotifyUserEventHandler(ByVal sender As Object, ByVal e
As EventArgs)

You can see this event handler if you use ILDASM.

Then under the covers VB.NET defined the event as:
Public Event NotifyUser As NotifyUserEventHandler

Which is why it's 'better' to use the "Event X As Handler" syntax above,
especially where your events do or can have the same parameter structure. A
lot of my events are defined "As EventHandler" for this reason.

'e' is another stupid name. It's a shorthand for EventArgs but it's
brevity goes against one of the key style principles of .NET, namely, long
names for better understanding*. I would have expected eventArgs, I usually get annoyed when its not e, or
the protected sub to raise the event changes the name: (override the
OnLayout method of a control for example).

Remember the standard event pattern recommends you define a protected
overridable sub to raise the event:

Protected Overridable Sub OnNotifyUser(ByVal e As EventArgs)
RaiseEvent NotifyUser(me, e)
End Sub

Which allows derived classes to override the above routine to get first
chance at handling the event, plus gives derived classes a chance to raise
the event.

[* However, saying that, I like g for Graphics! :-)] I normally prefer gr for Graphics! Not sure where I picked it up, must have
been some early example...

I mostly agree having a more specific names & types may be nice on the event
handlers, however part of OOP is generalization & code reuse. If you start
giving specifics you are introducing coupling...

Hope this helps
Jay

"Fergus Cooney" <fi******@tesco.net> wrote in message
news:eW**************@TK2MSFTNGP11.phx.gbl... Hi Jay,

I answered a query a while back about event handlers. It also talked about 'sender' and 'e'. I'm including the whole thing here, so bear with me - your answer is (mostly?) in there somewhere.

Regards,
Fergus

<post>
1 Private Sub TextBox1_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress
5 If e.KeyChar.IsNumber(e.KeyChar) Then
6 e.Handled = False
7 Else
8 e.Handled = True
9 End If
10 End Sub

When an event, like receiving a key press or a mouse action, occurs to a Control, in this case a TextBox, a message is sent to the Control to inform it about what's happened. All events that happen to Controls are handled by
built-in code but there is also the option for the <user> of the Control to take some additional action. In your case it's discarding non-digit
keystrokes. Finally, the Control may trigger an event <itself> specifically for the user. Dealing with events, ie. handling them, is optional.

You can hook into an event by installing what's called an Event Handler. This is a routine which takes a particular form as shown by lines 1 to 4. The 'Handles' keyword tells the compiler that this Sub will handle events 'raised' by the following Control and for the given event. In this case it's TextBox1 and the KeyPress event.

Note that this is a list and you can have more Controls, eg:
1 Private Sub AllMyTextBoxes_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress, TextBox2.KeyPress, _
5 txtAddressA.KeyPress, txtAddressB.KeyPress, etc

The name used in line 1 is completely arbitrary but the convention is to have the Control name, an underscore and then the event name.

The arguments to an event handler are predefined.

'sender' is the Control to which the event happened and is an Object. This is so that the same mechanism can be applied to any Object that can raise an Event. I don't like the name myself. I never think in terms of a Control or Object 'sending' an event. That, to me, is practically meaningless. I would prefer VB to insert 'TheTextBox' or some name tailored to the Control or
Object. Ah, well.

'e' is another stupid name. It's a shorthand for EventArgs but it's
brevity goes against one of the key style principles of .NET, namely, long
names for better understanding*. e is always an object containing information about the Event. In the case of a KeyPress, it will be KeyChar - the key that was pressed and Handled, a variable, the setting of which, allows you to
discard the keystroke. (Empty and GetType() are the other two, which I will ignore). [* However, saying that, I like g for Graphics! :-)]

Hooking into an Event.

This is done for you when you double-click a Form or Control, although it only works for the default event. VB will write the outline of the required Sub. You can get the other events for a Control by going into the top-left box above the code for the form (I don't know what the box is called but it
usually shows the Form name) and selecting (Base Class Events). This will
put - in the <top-right> box - the events that your control can handle. Click on the one you want and <that> event's Sub will be writen for you. Finally, if you know what you are doing, you can simply type it in.

[If you ever get into C#, hooking into events take a bit more effort and thereby teaches you the mechanism a bit better. You'll learn the same when you get into Delegates in VB.]

Ok, that's Events 101. Keep asking. We'll get you there! :-)

Regards,
Fergus
</post>

[Fergus Cooney]

Hi Jay,

|| > I would prefer VB to insert 'TheTextBox' or some name
|| > tailored to the Control or Object. Ah, well.
||
|| Interesting thought. What happens in the case where I have
|| MenuItem.Click, ToolBarButton.Click, Button.Click and
|| Form.Close all being handled by the same event handler? :-)

Lol. ... and <Form.Close>!! :-)

Yes, my scheme only works for dedicated handlers. But 'tis more than a
few. Actually it's an ideal. In use I leave sender and e as given. That's why
'Ah, well' because I can't battle against a never ending tide of VB defaults.
It's a shame that it's not an option, though it would possibly confuse those
who are bound to the convention. [Know any good code reformatters, eh? No,
<good> ones, lol.!!]

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender'
|| to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in me.
Thus I can have oDear As Mishap, and oGod As Deity. I'm still vascillating
over clsSomething versus plain Something.

|| Note that the EventHandler delegate is used by a significant number of
|| events. Which enables having only one Delegate class defined, rather
than
|| having a significant number of Delegate Classes... (code reuse). Hence
the
|| very generic names for the parameters.

Yes - that's what I meant by 'standard pattern' and when your post
appeared I saw that you had used it too.

Here's part of a set of classes that I have in C# that might make you
shudder.
public class VoidDelegates
{
public delegate void v_i (int iArg);
public delegate void v_s (string sArg);
public delegate void v_t (bool tArg);
public delegate void v_o (object oArg);
public delegate void v_ii (int iArg1, int iArg2);
public delegate void v_is (int iArg1, string sArg2);
public delegate void v_iii (int iArg1, int iArg2, int
iArg3);
public delegate void v_iis (int iArg1, int iArg2, string
sArg3);
public delegate void v_ss (string sArg1, string sArg2);
public delegate void v_so (string sArg1, object oArg2);
}
We're talking majorly <generic>!! It's used within a system that has no
knowledge of its users' semantics - it just takes 'em in and sends 'em out, as
it were.

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually used
the keyword 'Event' much. I find this area so much simpler in C# where it's
all out in the open. This VB behind-the-scenes helpfulness <is> helpful, but
it can delay the fullness of grokking.

|| > 'e' is another stupid name
|| I would have expected eventArgs

And, to be sure, Oid be after havin' oEventArgs, now. But yet again I go
with what's given. I'm going to have to undo my habit of Catch e As Exception,
though, and get used to using 'ex' so it doesn't clash with 'e'.

|| > ... I like g for Graphics!
|| I normally prefer gr for Graphics!

That I actually like better, and I'm going to steal it off you. ;-)

|| I mostly agree having a more specific names & types may be nice
|| on the event handlers, however part of OOP is generalization &
|| code reuse. If you start giving specifics you are introducing
coupling...

Yes. There are clear cases where close coupling is neither here nor there,
and yet others where it is to be avoided. And we can spend years umming and
ahhing about the grey areas and changing our mind one way and back as our
experience grows. At least I will. ;-) Some of my 'standards' are decidely
shifty in the longer term.

Best regards,
Fergus

ps. Thank you. It's been nice having this conversation with you. :-)) Much
relief - I was concerned that I had offended you in the IIM (not-a-) debate
and had thought out, though not sent, my apologies. And secondly, after a
battle last night with a (to me at least) rude poster, it's nice sharing an
understanding and being agreeable. It's my preferred state, lol, whatever he
may have thought.

[Jay B. Harlow [MVP - Outlook]]

Fergus,

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender'
|| to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in me. Thus I can have oDear As Mishap, and oGod As Deity. I'm still vascillating
over clsSomething versus plain Something. I've seen a number of Java programmers use 'a', 'an' and 'the' as I
understand it aids in readability, which I can see. Where 'a' & 'an' are one
of many, and 'the' is effectively a singleton (theApp, theMainForm,
theDatabase).

Dim aTextBox as TextBox
Dim theTextBox as TextBox

aTextBox.Text = "Hello World"
' a text box's text is hello world

theTextBox.Text = "Hello World"
' the text box's text is hello world

' of course sometimes it leads to awkwardness ;-)
For Each aControl In Controls
aControl.Name = Nothing
Next

I've gotten away from 'o' & 'obj' for object, along with 'c', 'C' & 'cls'
for Class.

When I prefix a name it tends to be a camel cased type name, I rarely use an
abbreviation.

Dim list As ArrayList
Dim listSource As ArrayList
Dim listDestination As ArrayList

(Yes one could argue that "list" above is an abbreviation, however I am
referring to abbreviations such as 'lst').
|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually used the keyword 'Event' much. I find this area so much simpler in C# where it's all out in the open. This VB behind-the-scenes helpfulness <is> helpful, but it can delay the fullness of grokking. I suspect a lot of VB.NET developers coming from VB6 would use my example
above. I use an existing Delegate if available otherwise I explicitly define
the Delegate and use the 'Event x As' syntax.

Something like:

Public Class NotifyUserEventArgs
Inherits EventArgs

End Class

Public Delegate Sub NotifyUserEventHandler(ByVal sender As Object, ByVal
e As MyEventArgs)

Public Class MyClass

Public Event NotifyUser As MyEventHandler

Protected Overridable Sub OnNotifyUser(ByVal e As MyEventArgs)
RaiseEvent NotifyUser(me, e)
End Sub

End Class

Of course if there are existing EventArgs & EventHandler classes/delegates
defined I use them instead of my own.

The only real difference I've noticed with the above & C#, is that
RaiseEvent hides the check for a null delegate.

Jay
"Fergus Cooney" <fi******@tesco.net> wrote in message
news:uz**************@tk2msftngp13.phx.gbl... Hi Jay,

|| > I would prefer VB to insert 'TheTextBox' or some name
|| > tailored to the Control or Object. Ah, well.
||
|| Interesting thought. What happens in the case where I have
|| MenuItem.Click, ToolBarButton.Click, Button.Click and
|| Form.Close all being handled by the same event handler? :-)

Lol. ... and <Form.Close>!! :-)

Yes, my scheme only works for dedicated handlers. But 'tis more than a
few. Actually it's an ideal. In use I leave sender and e as given. That's why 'Ah, well' because I can't battle against a never ending tide of VB defaults. It's a shame that it's not an option, though it would possibly confuse those who are bound to the convention. [Know any good code reformatters, eh? No,
<good> ones, lol.!!]

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender'
|| to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in me. Thus I can have oDear As Mishap, and oGod As Deity. I'm still vascillating
over clsSomething versus plain Something.

|| Note that the EventHandler delegate is used by a significant number of || events. Which enables having only one Delegate class defined, rather than
|| having a significant number of Delegate Classes... (code reuse). Hence the
|| very generic names for the parameters.

Yes - that's what I meant by 'standard pattern' and when your post
appeared I saw that you had used it too.

Here's part of a set of classes that I have in C# that might make you
shudder.
public class VoidDelegates
{
public delegate void v_i (int iArg);
public delegate void v_s (string sArg);
public delegate void v_t (bool tArg);
public delegate void v_o (object oArg);
public delegate void v_ii (int iArg1, int iArg2);
public delegate void v_is (int iArg1, string sArg2);
public delegate void v_iii (int iArg1, int iArg2, int iArg3);
public delegate void v_iis (int iArg1, int iArg2, string sArg3);
public delegate void v_ss (string sArg1, string sArg2);
public delegate void v_so (string sArg1, object oArg2);
}
We're talking majorly <generic>!! It's used within a system that has no knowledge of its users' semantics - it just takes 'em in and sends 'em out, as it were.

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually used the keyword 'Event' much. I find this area so much simpler in C# where it's all out in the open. This VB behind-the-scenes helpfulness <is> helpful, but it can delay the fullness of grokking.

|| > 'e' is another stupid name
|| I would have expected eventArgs

And, to be sure, Oid be after havin' oEventArgs, now. But yet again I go with what's given. I'm going to have to undo my habit of Catch e As Exception, though, and get used to using 'ex' so it doesn't clash with 'e'.

|| > ... I like g for Graphics!
|| I normally prefer gr for Graphics!

That I actually like better, and I'm going to steal it off you. ;-)

|| I mostly agree having a more specific names & types may be nice
|| on the event handlers, however part of OOP is generalization &
|| code reuse. If you start giving specifics you are introducing
coupling...

Yes. There are clear cases where close coupling is neither here nor there, and yet others where it is to be avoided. And we can spend years umming and ahhing about the grey areas and changing our mind one way and back as our
experience grows. At least I will. ;-) Some of my 'standards' are decidely
shifty in the longer term.

Best regards,
Fergus

ps. Thank you. It's been nice having this conversation with you. :-)) Much relief - I was concerned that I had offended you in the IIM (not-a-) debate and had thought out, though not sent, my apologies. And secondly, after a
battle last night with a (to me at least) rude poster, it's nice sharing an understanding and being agreeable. It's my preferred state, lol, whatever he may have thought.

[Tom Spink]

Hi Jay,

I personally *hate* camel casing. Just one of those things.

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:#1**************@TK2MSFTNGP12.phx.gbl...

Fergus,

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender' || to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in

me.

Thus I can have oDear As Mishap, and oGod As Deity. I'm still

vascillating over clsSomething versus plain Something.

I've seen a number of Java programmers use 'a', 'an' and 'the' as I
understand it aids in readability, which I can see. Where 'a' & 'an' are

one of many, and 'the' is effectively a singleton (theApp, theMainForm,
theDatabase).

Dim aTextBox as TextBox
Dim theTextBox as TextBox

aTextBox.Text = "Hello World"
' a text box's text is hello world

theTextBox.Text = "Hello World"
' the text box's text is hello world

' of course sometimes it leads to awkwardness ;-)
For Each aControl In Controls
aControl.Name = Nothing
Next

I've gotten away from 'o' & 'obj' for object, along with 'c', 'C' & 'cls'
for Class.

When I prefix a name it tends to be a camel cased type name, I rarely use an abbreviation.

Dim list As ArrayList
Dim listSource As ArrayList
Dim listDestination As ArrayList

(Yes one could argue that "list" above is an abbreviation, however I am
referring to abbreviations such as 'lst').

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually used

the keyword 'Event' much. I find this area so much simpler in C# where

it's

all out in the open. This VB behind-the-scenes helpfulness <is> helpful,

but

it can delay the fullness of grokking.

I suspect a lot of VB.NET developers coming from VB6 would use my example
above. I use an existing Delegate if available otherwise I explicitly

define the Delegate and use the 'Event x As' syntax.

Something like:

Public Class NotifyUserEventArgs
Inherits EventArgs

End Class

Public Delegate Sub NotifyUserEventHandler(ByVal sender As Object, ByVal e As MyEventArgs)

Public Class MyClass

Public Event NotifyUser As MyEventHandler

Protected Overridable Sub OnNotifyUser(ByVal e As MyEventArgs)
RaiseEvent NotifyUser(me, e)
End Sub

End Class

Of course if there are existing EventArgs & EventHandler classes/delegates
defined I use them instead of my own.

The only real difference I've noticed with the above & C#, is that
RaiseEvent hides the check for a null delegate.

Jay
"Fergus Cooney" <fi******@tesco.net> wrote in message
news:uz**************@tk2msftngp13.phx.gbl...

Hi Jay,

|| > I would prefer VB to insert 'TheTextBox' or some name
|| > tailored to the Control or Object. Ah, well.
||
|| Interesting thought. What happens in the case where I have
|| MenuItem.Click, ToolBarButton.Click, Button.Click and
|| Form.Close all being handled by the same event handler? :-)

Lol. ... and <Form.Close>!! :-)

Yes, my scheme only works for dedicated handlers. But 'tis more than a few. Actually it's an ideal. In use I leave sender and e as given. That's

why

'Ah, well' because I can't battle against a never ending tide of VB defaults.

It's a shame that it's not an option, though it would possibly confuse

those

who are bound to the convention. [Know any good code reformatters, eh?

No, <good> ones, lol.!!]

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender' || to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in me.

Thus I can have oDear As Mishap, and oGod As Deity. I'm still

vascillating over clsSomething versus plain Something.

|| Note that the EventHandler delegate is used by a significant number of

|| events. Which enables having only one Delegate class defined, rather

than
|| having a significant number of Delegate Classes... (code reuse).

Hence

the
|| very generic names for the parameters.

Yes - that's what I meant by 'standard pattern' and when your post
appeared I saw that you had used it too.

Here's part of a set of classes that I have in C# that might make

you shudder.
public class VoidDelegates
{
public delegate void v_i (int iArg);
public delegate void v_s (string sArg);
public delegate void v_t (bool tArg);
public delegate void v_o (object oArg);
public delegate void v_ii (int iArg1, int iArg2);
public delegate void v_is (int iArg1, string sArg2);
public delegate void v_iii (int iArg1, int iArg2,

int

iArg3);
public delegate void v_iis (int iArg1, int iArg2,

string

sArg3);
public delegate void v_ss (string sArg1, string sArg2);
public delegate void v_so (string sArg1, object oArg2);
}
We're talking majorly <generic>!! It's used within a system that has

no

knowledge of its users' semantics - it just takes 'em in and sends 'em

out, as

it were.

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually

used

the keyword 'Event' much. I find this area so much simpler in C# where

it's

all out in the open. This VB behind-the-scenes helpfulness <is> helpful,

but

it can delay the fullness of grokking.

|| > 'e' is another stupid name
|| I would have expected eventArgs

And, to be sure, Oid be after havin' oEventArgs, now. But yet again I go

with what's given. I'm going to have to undo my habit of Catch e As Exception,

though, and get used to using 'ex' so it doesn't clash with 'e'.

|| > ... I like g for Graphics!
|| I normally prefer gr for Graphics!

That I actually like better, and I'm going to steal it off you. ;-)

|| I mostly agree having a more specific names & types may be nice
|| on the event handlers, however part of OOP is generalization &
|| code reuse. If you start giving specifics you are introducing
coupling...

Yes. There are clear cases where close coupling is neither here nor

there,

and yet others where it is to be avoided. And we can spend years umming

and

ahhing about the grey areas and changing our mind one way and back as

our experience grows. At least I will. ;-) Some of my 'standards' are decidely shifty in the longer term.

Best regards,
Fergus

ps. Thank you. It's been nice having this conversation with you. :-))

Much

relief - I was concerned that I had offended you in the IIM (not-a-)

debate

and had thought out, though not sent, my apologies. And secondly, after a battle last night with a (to me at least) rude poster, it's nice sharing

an

understanding and being agreeable. It's my preferred state, lol,

whatever he

may have thought.

[Jay B. Harlow [MVP - Outlook]]

Tom,
I personally *hate* camel casing for method names! (which happens to be Java
convention).

For field and parameter names I use it without complaint, as it works.

Jay

"Tom Spink" <th**********@ntlworld.com> wrote in message
news:eF*************@TK2MSFTNGP11.phx.gbl...

Hi Jay,

I personally *hate* camel casing. Just one of those things.

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message news:#1**************@TK2MSFTNGP12.phx.gbl...

Fergus,

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender' || to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in

me.

Thus I can have oDear As Mishap, and oGod As Deity. I'm still vascillating over clsSomething versus plain Something. I've seen a number of Java programmers use 'a', 'an' and 'the' as I
understand it aids in readability, which I can see. Where 'a' & 'an' are

one

of many, and 'the' is effectively a singleton (theApp, theMainForm,
theDatabase).

Dim aTextBox as TextBox
Dim theTextBox as TextBox

aTextBox.Text = "Hello World"
' a text box's text is hello world

theTextBox.Text = "Hello World"
' the text box's text is hello world

' of course sometimes it leads to awkwardness ;-)
For Each aControl In Controls
aControl.Name = Nothing
Next

I've gotten away from 'o' & 'obj' for object, along with 'c', 'C' & 'cls' for Class.

When I prefix a name it tends to be a camel cased type name, I rarely use an

abbreviation.

Dim list As ArrayList
Dim listSource As ArrayList
Dim listDestination As ArrayList

(Yes one could argue that "list" above is an abbreviation, however I am
referring to abbreviations such as 'lst').

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually used

the keyword 'Event' much. I find this area so much simpler in C# where

it's

all out in the open. This VB behind-the-scenes helpfulness <is> helpful, but

it can delay the fullness of grokking.

I suspect a lot of VB.NET developers coming from VB6 would use my example above. I use an existing Delegate if available otherwise I explicitly

define

the Delegate and use the 'Event x As' syntax.

Something like:

Public Class NotifyUserEventArgs
Inherits EventArgs

End Class

Public Delegate Sub NotifyUserEventHandler(ByVal sender As Object,

ByVal

e As MyEventArgs)

Public Class MyClass

Public Event NotifyUser As MyEventHandler

Protected Overridable Sub OnNotifyUser(ByVal e As MyEventArgs)
RaiseEvent NotifyUser(me, e)
End Sub

End Class

Of course if there are existing EventArgs & EventHandler classes/delegates defined I use them instead of my own.

The only real difference I've noticed with the above & C#, is that
RaiseEvent hides the check for a null delegate.

Jay
"Fergus Cooney" <fi******@tesco.net> wrote in message
news:uz**************@tk2msftngp13.phx.gbl...

Hi Jay,

|| > I would prefer VB to insert 'TheTextBox' or some name
|| > tailored to the Control or Object. Ah, well.
||
|| Interesting thought. What happens in the case where I have
|| MenuItem.Click, ToolBarButton.Click, Button.Click and
|| Form.Close all being handled by the same event handler? :-)

Lol. ... and <Form.Close>!! :-)

Yes, my scheme only works for dedicated handlers. But 'tis more

than a few. Actually it's an ideal. In use I leave sender and e as given. That's

why

'Ah, well' because I can't battle against a never ending tide of VB defaults.

It's a shame that it's not an option, though it would possibly confuse

those

who are bound to the convention. [Know any good code reformatters, eh?

No, <good> ones, lol.!!]

|| I normally give 'theTextBox' or just 'textbox' when I cast 'sender' || to the specific type.

I've decided I'm going to stick to my 'o's. I think it's the Irish in

me.

Thus I can have oDear As Mishap, and oGod As Deity. I'm still

vascillating over clsSomething versus plain Something.

|| Note that the EventHandler delegate is used by a significant number

of

|| events. Which enables having only one Delegate class defined,

rather

than
|| having a significant number of Delegate Classes... (code

reuse). Hence

the
|| very generic names for the parameters.

Yes - that's what I meant by 'standard pattern' and when your post
appeared I saw that you had used it too.

Here's part of a set of classes that I have in C# that might make you shudder.
public class VoidDelegates
{
public delegate void v_i (int iArg);
public delegate void v_s (string sArg);
public delegate void v_t (bool tArg);
public delegate void v_o (object oArg);
public delegate void v_ii (int iArg1, int

iArg2); public delegate void v_is (int iArg1, string sArg2); public delegate void v_iii (int iArg1, int iArg2, int

iArg3);
public delegate void v_iis (int iArg1, int

iArg2, string

sArg3);
public delegate void v_ss (string sArg1, string

sArg2); public delegate void v_so (string sArg1, object oArg2); }
We're talking majorly <generic>!! It's used within a system that has no

knowledge of its users' semantics - it just takes 'em in and sends 'em

out, as

it were.

|| Public Event NotifyUser(ByVal sender As Object, _
|| ByVal e As EventArgs)

I must admit I haven't seen this one - in fact, I haven't actually

used

the keyword 'Event' much. I find this area so much simpler in C# where

it's

all out in the open. This VB behind-the-scenes helpfulness <is>

helpful, but

it can delay the fullness of grokking.

|| > 'e' is another stupid name
|| I would have expected eventArgs

And, to be sure, Oid be after havin' oEventArgs, now. But yet

again I

go

with what's given. I'm going to have to undo my habit of Catch e As Exception,

though, and get used to using 'ex' so it doesn't clash with 'e'.

|| > ... I like g for Graphics!
|| I normally prefer gr for Graphics!

That I actually like better, and I'm going to steal it off you.

;-)
|| I mostly agree having a more specific names & types may be nice
|| on the event handlers, however part of OOP is generalization &
|| code reuse. If you start giving specifics you are introducing
coupling...

Yes. There are clear cases where close coupling is neither here

nor there,

and yet others where it is to be avoided. And we can spend years

umming and

ahhing about the grey areas and changing our mind one way and back as our experience grows. At least I will. ;-) Some of my 'standards' are decidely shifty in the longer term.

Best regards,
Fergus

ps. Thank you. It's been nice having this conversation with you. :-))

Much

relief - I was concerned that I had offended you in the IIM (not-a-)

debate

and had thought out, though not sent, my apologies. And secondly,

after a battle last night with a (to me at least) rude poster, it's nice

sharing an

understanding and being agreeable. It's my preferred state, lol,

whatever

he

may have thought.