Chapter 1 : Chapter 1 Event-driven Programming 1
ASP.NET Web Server Control Event Model : ASP.NET Web Server Control Event Model An important feature of ASP.NET is that it allows you to program Web pages using an event-based
model that is similar to that in client applications. As a simple example, you can add a button to an
ASP.NET Web page and then write an event handler for the button's click event. Although this is
common in Web pages that work exclusively with client script (by handling the button's onclick event in
dynamic HTML), ASP.NET brings this model to server-based processing.
Events raised by ASP.NET server controls work somewhat differently than events in traditional HTML
pages or in client-based Web applications. The difference arises primarily because of the separation of
the event itself from where the event is handled. In client-based applications, events are raised and
handled on the client. In ASP.NET Web pages, however, events associated with server controls
originate on the client (browser) but are handled on the Web server by the ASP.NET page.
For events raised on the client, the ASP.NET Web control event model requires that the event
information be captured on the client and an event message transmitted to the server, through an
HTTP post. The page must interpret the post to determine what event occurred and then call the
appropriate method in your code on the server to handle the event. 2
Slide 3 : ASP.NET handles the task of capturing, transmitting, and interpreting the event. When you create
Event handlers in an ASP.NET Web page, you can typically do so without thinking about how the event
information is captured and made available to your code. Instead, you can create event handlers in
much the same way you would in a traditional client form. However, there are some aspects of event
handling in ASP.NET Web pages that you should be aware of.
Event Set for Server Controls and Pages
Because most ASP.NET server control events require a round trip to the server for processing, they
can affect the performance of a page. Therefore, server controls offer a limited set of events, usually
only click-type events. Some server controls support change events. For example, the CheckBox Web
server control raises a CheckedChanged event in server code when the user clicks the box. Some
server controls support more abstract events. For example, the Calendar Web server control raises a
SelectionChanged event that is a more abstract version of a click event.
Events that occur often (and can be raised without the user knowing it), such as an onmouseover
event, are not supported for server controls. ASP.NET server controls can still call client-side handlers
for those events. 3
Slide 4 : Controls and the page itself also raise life-cycle events at each processing step, such as Init, Load,
and PreRender. You can take advantage of these life-cycle events in your application. For example, in
a page's Load event, you can set default values for controls.
Event Arguments
Server-based ASP.NET page and control events follow a standard .NET Framework pattern for event
handler methods. All events pass two arguments: an object representing the object that raised the
event, and an event object containing any event-specific information. The second argument is usually
of type EventArgs, but for some controls is of a type specific to that control. For example, for an
ImageButton Web server control, the second argument is of type ImageClickEventArgs, which
includes information about the coordinates where the user has clicked.
Note Events for the page (for example, the page's Load event) can accept the standard two
arguments, but no values are passed in these arguments.
Postback and Non-Postback Events in Server Controls
In server controls, certain events, typically click events, cause the page to be posted back immediately
to the server. Change events in HTML server controls and Web server controls, such as the TextBox
control, do not immediately cause a post. Instead, they are raised the next time a post occurs. 4
Slide 5 : After a page has been posted back, the page's initialization events (Page_Init and Page_Load) are raised,
nd then control events are processed. You should not create application logic that relies on the change events
being raised in a specific order unless you have detailed knowledge of page event processing
If it useful for your application, you can specify that change events cause the page to post. Web server
controls that support a change event include an AutoPostBack property. When this property is true, the
control's change event causes the page to post immediately, without waiting for a click event. For example, by
default, a CheckBox control's CheckedChanged event does not cause the page to be submitted. However, if
you set the control's AutoPostBack property to true, as soon as a user clicks the check box, the page is sent
to the server for processing.
Forwarded Events
Web server controls such as the Repeater, DataList, GridView, FormView, and DetailsView controls can
Contain button controls that themselves raise events. For example, each row in a GridView control can
contain one or more buttons created dynamically by templates.
Rather than each button raising an event individually, events from the nested controls are forwarded to the
container control. The container in turn raises a generic ItemCommand event with parameters that allow you
to discover which individual control raised the original event. By responding to this single event, you can avoid
having to write individual event handlers for child controls.
The ItemCommand event includes the two standard event arguments, an object referencing the source of the
event and an event object containing event-specific information. 5
Slide 6 : With buttons, you can use the CommandArgument property to pass a user-specified string to the
vent handler to help you identify what button raised the event. For example, in a DataList control,
buttons raise the ItemCommand event. You can set the CommandArgument property of each button to
a different value—perhaps one button's value is "ShowDetails" and another button's value is
"AddToShoppingCart"—and then capture those values in the event handler later.
Binding Events to Methods
An event is a message like "a button has been clicked". In your application, the message must be
translated into a method call in your code. The binding between the event message and a specific
method—that is, an event handler—is done using an event delegate. For more information
In ASP.NET Web pages, you do not need to explicitly code delegates if the control is created
declaratively (in markup) on the page. Event binding can be accomplished in various ways, depending
on what event you are binding and what programming language you are using 6
Slide 7 : Binding Control Events
For controls declared on the page, you can bind an event to a method by setting an attribute (property) in the
control's markup. The following code example shows how to bind the Click event of an ASP.NET Button
control to a method named ButtonClick.
When the page is compiled, ASP.NET looks for a method named ButtonClick and confirms that the method
has the appropriate signature (it accepts two arguments, one of type Object and another of type EventArgs).
ASP.NET then automatically binds the event to the method.
Explicit Binding for Dynamic Controls
If you create controls by declaring them in markup, you can bind events to methods using an attribute (for
example, onclick) or in Visual Basic, by using the Handles keyword. If you create controls dynamically (in
code), you cannot use either of these methods, because the compiler does not have a reference to the control
At compilation time.
In that case, you must use explicit event binding. In Visual Basic, you can use the AddHandler statement to
Bind an event in a dynamically created control to an existing method. In C#, you create a delegate and
associate it with the control's event. The following code example shows how you can bind a method named
ButtonClick to a button's Click event: 7
Slide 8 : Button b = new Button;
b.Text = "Click";
b.Click += new System.EventHandler(ButtonClick);
Placeholder1.Controls.Add(b);
ASP.NET Page Life Cycle Overview
When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of
Processing steps. These include initialization, instantiating controls, restoring and maintaining state,
running event handler code, and rendering. It is important for you to understand the page life cycle so
that you can write code at the appropriate life-cycle stage for the effect you intend.
If you develop custom controls, you must be familiar with the page life cycle in order to correctly
Initialize controls, populate control properties with view-state data, and run control behavior code. The
life cycle of a control is based on the page life cycle, and the page raises many of the events that you
need to handle in a custom control. 8
Slide 9 : Page Life-Cycle Events 9
Slide 10 : 10
Slide 11 : 11
Slide 12 : 12
Slide 13 : 13