Alex said:
I'm working through the Beginning Visual Basic 2005 book, but I have a
question that though might be obvious, I'm not seeing an explanation.
THe first example in the book is creating a simple form with two
buttons and a text box, but for example on the OK button, here's waht
is in the .vb file for this object:
Private Sub btnOK_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles
End Sub
Can someone explain what all this is? I know btn_OK is the name I
gave the button, and _Click I assume is the action (when you click on
it, run this sub). But what's the rest, like everything in the
parenthesis? What does all this mean?
"Private" - this method is only accessible within the class that defines
it. Nothing outside of this class can use this method directly.
"Sub" - a method that doesn't return a value.
"btnOK_Click" - the method name. The /convention/ for Event Handlers
like this is <ControlName>_<EventName>. It's only a convention; there's
nothing to stop you calling this method "Fred".
"( ... )" - Arguments to the method. Since this is an event handler,
there's a convention for these as well ...
"ByVal sender as Object" - sender is a reference (dare I say "Pointer")
to the object that raised this event, /whatever/ that might be. It's
typed "As Object" because it really could be /any/ object you can
define, and Object is the base class for all other objects. Using this
reference, you can access the control that sent you the event, so that
you can manipulate it, but you have to know what Type it is:
Private Sub Button1_Click( _
ByVal sender as Object _
, byval e as EventArgs _
) Handles Button1.Click
DirectCast(sender, Button).Enabled = False
End Sub
"ByVal e as EventArgs" - e is a reference to an object that tells you
more about this particular event. In this case, there isn't much else
to say - the control got clicked on - but other events have some quite
extensive event arguments.
"Handles <ControlName>.<EventName>" - this may feel a bit redundant in
this case, because your event name and the actual event it's handling
are [almost] identical BUT, in the Brave New, Object-Oriented World.Net,
you can have one event handler .. er .. handling the events from more
than one object, as in ...
Private Sub AnyButton_Click( _
ByVal sender as Object _
, byval e as EventArgs _
) Handles Button1.Click, Button2.Click, Button3.Click
' This routine is called when ANY
' of the three buttons is clicked
End Sub
.... and more than one event handler handling the /same/ event from a
single control, as in ...
Private Sub Button1_Click( _
ByVal sender as Object _
, byval e as EventArgs _
) Handles Button1.Click
' Button1's own "click" handler
End Sub
Private Sub Poacher( _
ByVal sender as Object _
, byval e as EventArgs _
) Handles Button1.Click
' This one ALSO gets called when Button1 is clicked!
' AFAIK, you can't guarantee the order they're called in.
End Sub
You may also see the "AddHandler" statement in people's code
(particularly if you get C# samples). This statement does the same
thing as (and, indeed, replaces) the "Handles" clause, but does it at
/run-time/ and is used when, say, you're adding Controls dynamically but
still need to handle their events.
AddHandler Button4.Click, AddressOf Button4_Click
HTH,
Phill W.