Section 19.2. Web Form Events

19.2. Web Form Events

Web Forms are event-driven. An event represents the idea that "something happened ." An event is generated (or raised ) when the user clicks a button, or selects from a ListBox , or otherwise interacts with the UI. Events can also be generated by the system starting or finishing work. For example, open a file for reading, and the system raises an event when the file has been read into memory.

The method that responds to the event is called the event handler . Event handlers are written in C# and are associated with controls in the HTML page through control attributes.

By convention, ASP.NET event handlers return void and take two parameters. The first parameter represents the object raising the event. The second, called the event argument , contains information specific to the event, if any. For most events, the event argument is of type EventArgs , which has no members and serves as a placeholder and as the base class for more specialized objects that provide properties needed by the event handler.

In web applications, most events are handled on the server and, therefore, require a round trip. ASP.NET supports only a limited set of events, such as button clicks and text changes. These are events that the user might expect to cause a significant change, as opposed to Windows events (such as mouse-over) that might happen many times during a single user-driven task.

19.2.1. Postback Versus Non-Postback Events

Postback events are those that cause the form to be sent (or posted) to the server and then to be returned to the browser (typically with updated data) The user's experience is that the page is updated after a brief delay.

A button click, for example, causes the page to be sent to the browser, the event handlers are run, and then the same page is sent back to the browser.

To avoid this round trip to the server happening too frequently, many events such as changing the text in a textbox or clicking a checkbox are non-postback events. When these events fire, the form is not posted back, but the event is saved by the control, and handled the next time the page is posted back.

You can force non-postback controls to act as if they are postback controls by setting their AutoPostBack property to true .

19.2.2. State

The web does not maintain state. By design, it is a stateless environment. That means that the server would normally have no idea that a second post from a given user has any association with previous posts by that same user. That is fine if all you have are one or two pages that are information only, with no interaction, but it is obviously limiting if you want to create an interactive application.

ASP.NET solves this problem by maintaining three types of state: view state, session state, and application state:

View state

Maintains the value of controls (what you've filled into text boxes, which choices you've made in lists) when you post a page to the server. There was a time you had to write code to do this, but it is now done for you in an efficient and reliable manner.

Session state

Creates an artificial "connection" with the application, simulating the idea of an ongoing session for an individual user within a single application. This is so natural, you hardly notice it. You go to a site, and as you interact with it, remembers your input and responds accordingly , just like working with a desktop application. Sessions typically end by "timing out" after about 20 minutes of inactivity; but in most cases, this is invisible to the user.

Application state

Preserves values across users within a given web application. Application state is beyond the scope of this chapter.