The .
NET Framework Event Model: Delegates and Events
You will also see from the earlier example that the above code does exactly the same thing as the following
code:
FireIt(Roc, RocLoc)
As soon as RaiseEvent is invoked the Delegate calls the Receiver, passes in the coordinates and the name of
the asteroid to zap and that rock is history.
There are a number of other classes that flesh out this event model. First, an information class is defined to
hold any data you need to pass to the Receiver. This would be useful for the other users of the Weapons
class, like the Weapons Officer or a database. This can be any class derived from EventArgs, a framework
class you must inherit from. While you have no direct control over the EventArgs base−class, you can
nevertheless override certain functionality from it. This code provides an example of such specialization in
this class:
Public Class LaserEventArgs
Inherits EventArgs
Public ReadOnly Property Information () As String
' ...
End Property
' ...
End Class
Second, you can also name the Delegate with event handling semanticstypically by suffixing the identifier
with the words EventHandler, as in AsteroidSightedEvent Handler. The so−called EventHandler works
like any Delegate discussed earlier, so don't be confused when you see it littered all over your GUI
applications. It can be unicast or multicast, and it encapsulates the reference (binds) to a method or methods in
the EventArgs specialization. The following code provides an example of an event− handler Delegate for the
Trajectory application:
Public Delegate Sub AsteroidEnterEventHandler(sender As Object, _
e As LaserEventArgs)
If you do not need to provide data to the target of the Delegate, you can simply use the default event Delegate
provided by the framework at System.EventHandler as follows:
Public Event NoDataEventHandler As EventHandler
This serves the purpose of simply binding the occurrence to the no−data event handler.
Third, an event is defined in the client code using the Event keyword and this syntax:
[ <attrlist> ] [ Public | Private | Protected | Friend | Protected Friend ] _
[ Shadows ] Event eventname[(arglist)] _
[ Implements interfacename.interfaceeventname ]
Fourth, you should also provide a methodpreferably prefixed with the word On, as in OnAsteroidEnterthat
raises the event in your application. This makes it easier to understand what's going on in the application,
although at times it seems to be a waste to move the RaiseEvent statement to another method, possibly far
way from the point it was raised. Using On is not required, but this style helps distinguish event methods in
your code and helps render your applications easier to follow and maintain. Calling the OnAsteroidEnter or
488
