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