Event Bubbling

ASP.Net page design permits for the nesting of controls. For example, the Repeater and DataGrid control can contain buttons that let the user take actions such as editing or deleting a data row.

Rather than having these buttons all generate their own separate events, the event — Click, in this case — is bubbled to the container. In turn, the container raises the generic ItemCommand event, which includes the information required to determine which individual nested control was clicked.

This bubbling model simplifies your task as the programmer because you can write a single event handler to respond to all events from the nested controls, rather than having to write individual handlers for all of them.

Event Delegates

So far, we have seen that ASP.Net is designed so that the code on the server is informed of user events by a postback, and that the number and frequency of user events is kept at a minimum to reduce the impact on page response. When the server receives a postback for an event, it is in essence nothing more than a message saying something like "Button1 has been clicked."

Obviously, the messages have to be translated into action; in other words, the event messages have to trigger execution of the appropriate procedure. This is done using delegates.

For most programming situations, and when Visual Studio is used, you do not have to take any special steps to create the required delegate to wire an event to its handler; it is done for you. In Visual Basic this is done using the Handles keyword. For example, here's the Click event procedure for a Button control:

Private Sub Button1_Click(ByVal sender
 As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
End Sub

This is just an ordinary procedure, except for two things:

• It has the correct signature — number and type of arguments — that is required to accept the information that is sent from the client when a Button control is clicked.
• The Handles keyword connects the procedure to the actual event.

When you let Visual Studio create your event handlers, it uses the traditional event procedure naming rules: ControlName_EventName. Unlike Visual Basic 6, however, this name is not required. It is not the procedure name but the Handles keyword that connects the procedure to the event.

C# works a bit differently. The Visual-Studio created event procedure is given the same descriptive name, as shown here, but nothing in the procedure itself connects it to the event, although the required arguments are present:

private void Button1_Click(object sender, System.EventArgs e)

Rather, the connection — that is, the delegate — is created separately in the normally hidden Web Form Designer Generated Code section:

this.Button1.Click += new System.EventHandler(this.Button1_Click);

Using delegates rather than procedure names to connect events to event handlers provides you with greater flexibility. For example, you can connect a single procedure to multiple events. In Visual Basic:

Sub MultipleButtonClickHandler (ByVal sender as System.Object, _
   ByVal e as System.EventArgs) _
   Handles Button1.Click, Button2.Click, Button3.Click

In C#, you can use the Events button in the properties window for the control, or write the delegate definitions yourself:

this.Button1.Click += new 
System.EventHandler(this.MultipleButtonEventHandler);
this.Button2.Click += new System.EventHandler(this.MultipleButtonEventHandler);
this.Button3.Click += new System.EventHandler(this.MultipleButtonEventHandler);

When you use this technique, you can determine which of the multiple controls caused the event by using the sender argument. Assign it to a variable in the event procedure, casting it to the proper type, and then retrieve the ID property to identify the specific control:

Sub MultipleButtonClickHandler (ByVal sender as System.Object, _
   ByVal e as System.EventArgs) _
   Handles Button1.Click, Button2.Click, Button3.Click
    Dim btn As Button
    btn = CType(sender, Button)
   Select Case btn.ID
   ....
   End Select
End Sub

Summing Up

ASP.Net's event model is designed to work efficiently in a client-server model that executes most if not all of a Web application's code on the server. It strikes a balance between providing a rich set of events and maintaining quick response. By using delegates to wire events to code it provides the programmer with additional flexibility not found in most older event models.