Responding to Both Client and Server Events in ASP.NET Server Controls

For the most part, you will be primarily interested in events that are raised in server code. However, if it is appropriate for your application, you can also handle client-side events for ASP.NET server controls by writing client script.

Note   You cannot use HTML syntax to bind to client-side events for Web server controls. Instead, you have to add event-binding attributes in code. For an example, see the table below.

For example, you might have an HTML image button element that you have converted to an HTML server 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 example, the assumption is that you are working with a browser that supports HTML 4.0, such as Microsoft Internet Explorer 4.0 or later.)

Note   In the case that both the client-side event handler and a server-side event handler have the same event-handler name, the client-side event handler always runs first, then the server event handler. However, it is confusing to allow this scenario, so some planning for a naming convention is strongly suggested.

Handling a Click Event in Client and Server Code

There is one event — the client onclick event — that introduces a difficulty if you want to handle it on both the client and the server. The problem arises because all button server controls (and other controls whose AutoPostBack property is set to true) submit the page to the server. However, in HTML, only a few controls inherently submit a form:

• The HTML submit button (<INPUT type=submit>), which is the HtmlInputButton control with its type set to Submit or Image. You can add this control from the HTML tab of the Toolbox.
• The Button Web server control (<asp:button>).

For all other controls that are specified to submit the page, a small client script is written into the page and called to submit the form when the control is clicked. Those controls therefore already use the client-side OnClick event to invoke this submit script.

You can create client-side OnClick handlers for all controls, but you need to choose the approach that works with each type of control. The following table summarizes the strategies you use for different types of controls.

f

Control	Strategy
HtmlInputButton, which includes HTML server control buttons whose type is set to Submit, Reset, or Image	Include an onclick attribute in the HTML syntax for the control: <INPUT Type="Submit" Runat="Server" Value="caption" onclick="clientfunction()" ...> On the server side, these types of buttons raise a ServerClick event instead of a simple Click event. The client event is raised first, and then the form is submitted and the server event is handled.
All other HTML controls (those that do not submit a form by default)	Include an onclick attribute in the HTML syntax for the control, but follow it with a semicolon (;): <INPUT Type="Button" Runat="Server" Value="caption" onclick="clientfunction();" ...> This causes your function to be called first, before the client-side submit script is called.
Web server controls, including buttons (<asp:button>) and other controls (for example, <asp:checkbox>)	You cannot specify a client-side event in the HTML syntax for a Web server control. Instead, add an event attribute to the control at run time in server code using code such as the following: Button1.Attributes.Add("onclick", "clientfunction();") Note   For the Button Web server control, you do not need the semicolon, because that control automatically submits the page.

Application and Session Events

In addition to page and control events, the ASP.NET page framework provides ways for you to work with events that can be raised when your application starts or stops or when an individual user's session starts or stops:

• Application events are raised for all requests to an application. For example, Application_BeginRequest is raised when any Web Forms page or XML Web service in your application is requested. This event allows you to initialize resources that will be used for each request to the application. A corresponding event, Application_EndRequest, provides you with an opportunity to close or otherwise dispose of resources used for the request.
• Session events are similar to application events (there is a Session_OnStart and a Session_OnEnd event), but are raised with each unique session within the application. A session begins when a user requests a page for the first time from your application and ends either when your application explicitly closes the session or when the session times out.

You can create handlers for these types of events in the Global.asax file. For details, see The Global.asax File and Global.asax Syntax.