Events in Web Forms work somewhat differently than events in traditional client forms 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 Web Forms, on the other hand, most events are raised on the client but handled on the Web server. (The page raises events on the server, as do some controls, such as the Calendar and Ad Rotator Web controls.)
For events raised on the client, the Web Forms event model requires that the event information be captured on the client and an event message transmitted to the server. Because of the way the Web works, this must happen via an HTTP post. The Web Forms framework must interpret the post to determine what event occurred, and then call the appropriate method in your code to handle the event.
The Web Forms framework handles virtually all of the mechanics of capturing, transmitting, and interpreting the event. When you create event handlers in a Web Forms page, you can do so without thinking about the mechanics of how the event information is captured and made available to you. Instead, you can create event handlers in much the same way you would do so in a traditional client form.
Even so, there are some aspects of event handling in Web Forms that you should be aware of.
Because most Web Forms events require a round trip to the server for processing, they can affect the performance of a form. As a consequence, controls in Web Forms offer a limited set of intrinsic events, usually limited to click-type events. Some controls support a special version of a change event, which is raised when the control's value changes. For example, the CheckBox control raises a change event when the user clicks the box. Events that occur often (and can be raised without the user knowing it), such as a mouseover event, are not supported for Web Forms controls.
Note Some controls support a set of higher-level events. For example, the Calendar control supports an OnSelectionChanged event that is a more abstract version of a click event.
Web and HTML control events follow a standard NGWS pattern for event methods. All events pass two arguments: an object representing the object that raised the event, and an event object containing event-specific information, if any. 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 control, the second argument is of the type ImageClickEventArgs, which includes information about the coordinates where the user clicked.
In Web controls (not HTML controls), by default, only click events cause the form to be posted back to the server. Change events are captured, but do not immediately cause a post. Instead, they are cached by the control until the next time that a post occurs. Then, when the page is processed on the server again, all the pending events are raised and processed. During server page processing, all change events are processed first, in no particular order. When all change events have been processed, the click event that caused the form to be posted is processed.
Note You should not create application logic that relies on the change events being raised in a specific order.
You can specify that a change event causes a form post. Controls that support a change event include an AutoPostBack property. When this property is true, the control's change event causes the form to post immediately, without waiting for a click event.
Controls such as the Repeater, DataList, DataGrid Web controls can contain child controls that themselves raise events. For example, each row in a DataGrid Web 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 "bubbled" — that is, they're sent to the container. The container in turn raises a generic event called OnItemCommand 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 OnItemCommand event includes the two standard event arguments, an object referencing the source of the event and a second event object containing event-specific information.
Note The DataGrid and DataList Web controls support additional events, such as OnEditCommand and OnDeleteCommand, which are special cases of bubbled events.
Web controls support only server-side events. However, the core set of HTML controls (buttons and text boxes) allow you to create event-handling methods for either client or server events. As with events for Web Forms controls, the server-side events or HTML controls are usually limited to a single event such as click or change. The remaining events are available for you to handle in client script.
For example, you might have an HTML image button element that you converted to an HTML control. Typically, in a Web Forms page you would handle the image button's click event in server code. However, you might also want to use client code to change the image when the user moves the mouse over it. You can do that by creating a client script for the image button's onmouseover event. (In this case, the assumption is that you are working with a browser that supports HTML 4.0, such as Microsoft® Internet Explorer 4.0 or later.)
You cannot create event-handling methods in client and server code for the same event. For example, you cannot create an OnServerClick event for an HTML button and also a client-side onclick event-handling method for the same button. When you create a server-side event handling method for an HTML control, the Web Forms framework overrides the corresponding client event in order to transmit the event information to the server.
In addition to page and control events, the ASP+ framework provides higher-level events:
See Also