11 out of 19 rated this helpful - Rate this topic

Events and Delegates

An event is a message sent by an object to signal the occurrence of an action. The action could be caused by user interaction, such as a mouse click, or it could be triggered by some other program logic. The object that raises the event is called the event sender. The object that captures the event and responds to it is called the event receiver.

In event communication, the event sender class does not know which object or method will receive (handle) the events it raises. What is needed is an intermediary (or pointer-like mechanism) between the source and the receiver. The .NET Framework defines a special type (Delegate) that provides the functionality of a function pointer.

A delegate is a class that can hold a reference to a method. Unlike other classes, a delegate class has a signature, and it can hold references only to methods that match its signature. A delegate is thus equivalent to a type-safe function pointer or a callback. While delegates have other uses, the discussion here focuses on the event handling functionality of delegates. A delegate declaration is sufficient to define a delegate class. The declaration supplies the signature of the delegate, and the common language runtime provides the implementation. The following example shows an event delegate declaration.


public delegate void AlarmEventHandler(object sender, AlarmEventArgs e);


The syntax is similar to that of a method declaration; however, the delegate keyword informs the compiler that AlarmEventHandler is a delegate type. By convention, event delegates in the .NET Framework have two parameters, the source that raised the event and the data for the event.

An instance of the AlarmEventHandler delegate can bind to any method that matches its signature, such as the AlarmRang method of the WakeMeUp class shown in the following example.


public class WakeMeUp
{
    // AlarmRang has the same signature as AlarmEventHandler.
    public void AlarmRang(object sender, AlarmEventArgs e)
    {
        //...
    }
    //...
}


Custom event delegates are needed only when an event generates event data. Many events, including some user-interface events such as mouse clicks, do not generate event data. In such situations, the event delegate provided in the class library for the no-data event, System.EventHandler, is adequate. Its declaration follows.


delegate void EventHandler(object sender, EventArgs e);


Event delegates are multicast, which means that they can hold references to more than one event handling method. For details, see Delegate. Delegates allow for flexibility and fine-grain control in event handling. A delegate acts as an event dispatcher for the class that raises the event by maintaining a list of registered event handlers for the event.

For details on using delegates to provide event functionality in your component or control, see Raising an Event.

For an overview of consuming events in your applications, see Consuming Events.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Conditional Events
$0Conditional Events are events that provide a way for each$0 $0consumer or listener to have events they receive filtered $0 $0by some listener-provided condition. $0 $0 $0 $0 $0$0 $0 $0 $0 $0 $0 $0 $0 $0In-concept, a conditional event would be functionally$0 $0 $0 $0 $0identical to the case where the event handler invokes $0 $0the predicate and simply returns if it is false:$0 $0 $0 $0$0 $0 $0 $0 $0 $0 $0$0 $0 $0 $0
    private void PropertyChanged( object sender, PropertyChangeEventArgs e )
   {
   if( predicate( e ) )
   {
   // listener wants to do something with this event
   }
   // else listener doesn't care about this event.
   }
$0
$0 $0 $0$0 $0 $0 $0 $0 $0 $0$0 $0 $0 $0 $0 $0 $0The basic idea, is to give the source of the event the$0 $0 $0 $0predicate, that it would use to determine if the event$0 $0should be fired at the listener. What purpose does it$0 $0serve?  It serves to avoid the overhead of invoking and $0 $0handling the event (e.g., in cases where the predicate $0 $0would otherwise have to be executed by the listener in$0 $0any case).$0 $0 $0$0 $0 $0 $0 $0 $0This idea is of course, founded on an assumption that$0 $0 $0 $0having the event source invoke the predicate would be$0 $0considerably cheaper than firing the event and requiring$0 $0the handler to invoke the functional equivalent of the $0 $0same predicate.$0 $0 $0$0 $0 $0 $0 $0Comments?$0 $0
Performance Tip
In the SP1 release of Visual Studio, a fix was made to the Event class, which makes it considerably faster than DelegateEvent. Therefore, you should use Event rather than DelegateEvent. Event has all the features of DelegateEvent, with the addition of implementing IObservable. But even if you do not need the functionality of IObservable, the performance advantage of Event makes it worthwhile to use Event rather than DelegateEvent even if you do not need the IObservable functionality.
Events/Delegates vs. Fields/Properties
The event delegate model is similar to field property model as both define private field which is not exposed to the outside world and methods for working with them but in Properties there are two types of methods viz. get and set while in events there is only for set viz. add_EventName and remove_EventName by using Delegate.Combine() and Delegate.Remove() for setting values to the delegate field. So in one way we can say that event keyword is just replacement of properties but for particular case of delegates types.
In .Net 2.0 and later, you should use EventHandler<T>
.Net 2.0 introduces the generic EventHandler<T> delegate, which can be used instead of creating a custom AlarmEventHandler delegate (EventHandler<AlarmEventArgs>)