Events owe their livelihood to delegates. Before reading
this you should understand that delegates allow you to call a method indirectly
through the delegate construct. The focus in discussing events here is not to
go into an in depth analysis of invoking and handling different events in
Windows Forms and the .NET Framework. Instead, the focus is to see how
delegates and events work together and how you can create and use them to add
flexibility and maturity to any type of application. Let’s take a look at a
fresh example. This example handles events for when a record is read from a
database. See Listing 4.
Listing 4 – Define a new delegate
Here we follow the traditional event programming idiom of
passing the object reference of the sender along with an object inheriting from
System.EventArgs that contains specific event information.
Listing 5 – Define the Event
Here we have an event and a method to raise the event. Both
of these are internal to a class named Transform. The event is defined
in terms of the delegate type. And the method OnRecordRead is called
internally, which in turn raises the event up to the event. Let’s now see how
a class hooks this up in Listing 6.
Listing 6 – Application using the event
Now we’re really getting somewhere. What you see in Listing
6 is a class named Client. Inside of Client a new instance of
the class Transform is instantiated. Next, a handler is wired up to the RecordReadEvent
that matches the delegate type of RecordReadEventHandler. And finally,
the method HandlReadRead actually handles the information, or events, that are
published. In essence, Client is acting as a subscriber to the
information that Transform is publishing. Listing 7 below ties these
last three diagrams all together.
Listing 7 – Tying it all together