Consuming Events 

To consume an event in an application, you must provide an event handler (an event-handling method) that executes program logic in response to the event and register the event handler with the event source. This process is referred to as event wiring. The visual designers for Windows Forms and Web Forms provide rapid application development (RAD) tools that simplify or hide the details of event wiring.

This topic describes the general pattern of handling events. For an overview of the event model in the .NET Framework, see Events and Delegates. For more information about the event model in Windows Forms, see How to: Consume Events in a Windows Forms Application. For more information about the event model in Web Forms, see How to: Consume Events in a Web Forms Application.

The Event Pattern

The details of event wiring differ in Windows Forms and Web Forms because of the different levels of support provided by different RAD tools. However, both scenarios follow the same event pattern, which has the following characteristics:

• A class that raises an event named EventName has the following member:

  public event EventNameEventHandler EventName;
  

  Public Event EventName As EventNameEventHandler
  

• The event delegate for the EventName event is EventNameEventHandler, with the following signature:

  public delegate void EventNameEventHandler(object sender, EventNameEventArgs e);
  

  Public Delegate Sub EventNameEventHandler(sender As Object, e As EventNameEventArgs)
  

To consume the EventName event, your event handler must have the same signature as the event delegate:

void EventHandler(object sender, EventNameEventArgs e) {}

Sub EventHandler(sender As Object, e As EventNameEventArgs)

Note
An event delegate in the .NET Framework is named EventNameEventHandler, while the term event handler in the documentation refers to an event-handling method. The logic behind the naming scheme is that an EventNameEventHandler delegate points to the event handler (the method) that actually handles the event.

When an event does not have any associated data, the class raising the event uses System.EventHandler as the delegate and System.EventArgs for the event data. Events that have associated data use classes that derive from EventArgs for the event data type, and the corresponding event delegate type. For example, if you want to handle a MouseUp event in a Windows Forms application, the event data class is MouseEventArgs and the event delegate is MouseEventHandler. Note that several mouse events use a common class for event data and a common event delegate, so the naming scheme does not exactly match the convention described above. For the mouse events, your event handler must have the following signature:

void Mouse_Moved(object sender, MouseEventArgs e){}

Sub Mouse_Moved(sender As Object, e As MouseEventArgs)

The sender and event argument parameters supply additional details about the mouse event to the event handler. The sender object indicates what raised the event. The MouseEventArgs parameter provides details on the mouse movement that raised the event. Many event sources provide additional data for the event, and many event handlers use the event-specific data in processing the event. For an example that demonstrates raising and handling events with event-specific data, see How to: Raise and Consume Events.

Note
Events also arise outside the context of user interfaces (UIs), and, in fact, the .NET Framework includes many non-UI classes that raise events. However, all events follow the pattern described here.

For information about raising events from a class, see Raising an Event.

See Also

Tasks

How to: Consume Events in a Web Forms Application
How to: Consume Events in a Windows Forms Application

Concepts

Events and Delegates
Raising an Event

Other Resources

Handling and Raising Events