Events in Visual C#.NET

Draw Code 128A in Visual C#.NET Events

GUIs, such as Microsoft Windows and web browsers, require that programs respond to events. An event might be a button click, a menu selection, the completion of a file transfer, and so forth. In short, something happens and you must respond to it. You cannot predict the order in which events will arise. The system is quiescent until the event, and then springs into action to handle it.

In a GUI environment, any number of controls can raise an event. For example, when you click a button, it might raise the Click event. When you add to a dropdown list, it might raise a ListChanged event. Other classes will be interested in responding to these events. How they respond is not of interest to the class raising the event. The button says, I was clicked, and the responding classes react appropriately.

In C#, any object can publish a set of events to which other classes can subscribe. When the publishing class raises an event, all the subscribed classes are notified. With this mechanism, your object can say, Here are things I can notify you about, and other classes might sign up, saying, Yes, let me know when that happens. For example, a button might notify any number of interested observers when it is clicked. The button is called the publisher because the button publishes the Click event and the other classes are the subscribers because they subscribe to the Click event. Note that the publishing class does not know or care who (if anyone) subscribes; it just raises the event. Who responds to that event, and how they respond, is not the concern of the publishing class.

This design implements the Publish/Subscribe (Observer) Pattern described in the seminal work Design Patterns by Erich Gamma et al. (Addison-Wesley).

As a second example, a Clock might notify interested classes whenever the time changes by one second. The Clock class could itself be responsible for the user interface representation of the time, rather than raising an event, so why bother with the indirection of using delegates The advantage of the publish/subscribe idiom is that the Clock class doesn t need to know how its information will be used; this way, the monitoring of the time is decoupled from the representation of that information, just as in the previous example the request to play the media was decoupled from the details of the player itself. In addition, any number of classes can be notified when an event is raised. The subscribing classes do not need to know how the Clock works, and the Clock does not need to know what they are going to do in response to the event. The subscribing classes don t need to know about each other, either. The publisher and the subscribers are decoupled by the delegate. This is highly desirable; it makes for more flexible and robust code. The Clock can change how it detects time without breaking any of the subscribing classes. The subscribing classes can change how they respond to time changes without breaking the Clock. Publishers and subscribers operate independently of one another, and that makes for code that is easier to maintain.

|

Events in C# are implemented with delegates. The publishing class defines a delegate. The subscribing class does two things: first, it creates a method that matches the signature of the delegate, and then it creates an instance of that delegate type encapsulating that method. When the event is raised, the subscribing class s methods are invoked through the delegate. A method that handles an event is called an event handler. You can declare your event handlers as you would any other delegate. By convention, event handlers in the .NET Framework always return void and take two parameters. The first parameter is the source of the event (that is, the publishing object). The second parameter is an object derived from EventArgs. Your event handlers will need to follow this design pattern.

EventArgs is the base class for all event data. Other than its constructor, the EventArgs class inherits all its methods from Object, though it does add a public static field named Empty, which represents an event with no state (to allow for the efficient use of events with no state). In other words, the EventArgs class is an empty

bucket that you can use to supply any information you want about the event, or no information at all. What the subscribing class does with that information is the subscriber s business; it doesn t matter to the publisher. In this way, the subscribing class can easily match the required delegate signature, by simply taking a parameter of type EventArgs. The subscriber might use all, some, or none of the information passed in EventArgs; it doesn t matter. Suppose you want to create a Clock class that uses delegates to notify potential subscribers whenever the local time changes its value by one second. Call this delegate SecondChangeHandler. The declaration for the SecondChangeHandler delegate is:

public delegate void SecondChangeHandler( object clock, TimeInfoEventArgs timeInformation);

This delegate will encapsulate any method that returns void and that takes two parameters. The first parameter is an object that represents the Clock (the object raising the event), and the second parameter is an object of type TimeInfoEventArgs, derived from EventArgs, that will contain useful information for anyone interested in this event. TimeInfoEventArgs is defined as follows:

public class TimeInfoEventArgs : EventArgs { public int hour; public int minute; public int second; public TimeInfoEventArgs(int hour, int minute, int second) {