]Interesting thought. What happens in the case where I have MenuItem.Click,
I would have expected eventArgs, I usually get annoyed when its not e, or
I normally prefer gr for Graphics! Not sure where I picked it up, must have[* However, saying that, I like g for Graphics!
Fergus Cooney said: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>
) MuchI've seen a number of Java programmers use 'a', 'an' and 'the' as I
I suspect a lot of VB.NET developers coming from VB6 would use my example
Fergus Cooney said: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.
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 said:Fergus,inI'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').
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
That'sFergus Cooney said: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.innumberIwhatevergo
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.
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,
Tom Spink said: