I don't know if you remember the first release of Visual Basic, but I sure do. It was a real breakthrough, mostly because of the ease of designing your program's visual interface.

A close second in its innovation was, at least in my opinion, the way VB handled events such as mouse clicks and key presses. It seems like old hat now, but back then it was a major breakthrough to respond to user events with essentially no hassle.

Responding to user events remains a central part of most applications, in both the traditional desktop programs and those that are web-based. The latter category provides special challenges: the program consists of a local component running on the client system and a remote component running on the server.

The .Net framework provides an excellent set of mechanisms for dealing with this dual-location event architecture. It's somewhat complex, however, and you need a good understanding of how exactly it works if you are to get the most out of it. My goal in this article is to provide a clear explanation of the ASP.Net event model. Along the way we will look at some other aspects of ASP.Net as well.

Note that this discussion does not apply to local events that are handled entirely by the browser. These events use JavaScript and the DHTML model to provide effects such as hover buttons and fly-out menus. They have been available for many years and are not specifically part of the .Net framework although they are available to the ASP.Net developer.

The Event Model

When an event on the client has to be processed on the server, there is no getting away from the need for communication between the two. The event is captured on the client and transmitted to the server via an HTTP post. The server processes the event and takes the appropriate action which may include updating the page on the client. The action is up to the programmer; an event can, of course, be ignored. This post-and-respond action is called a round trip because information has to go from the client to the server and then back to the client.

Even with today's speedy networks, round trips can affect a form's perceived performance. To minimize the performance hit, ASP.Net controls were designed with a very limited number of intrinsic events. Generally they fall into three categories:

• A Click event: for example, the Button control.
• A Change event: for example, the CheckBox control.
• Control-specific events: for example, the Calendar control's SelectionChanged event.

Many events that you may be used to programming with, such as MouseOver, are not supported because they would slow things down too much.

Another way that the ASP.Net event model minimizes the performance penalty is to designate some events as non-postback events. When the event occurs it is captured but not immediately posted to the server. The next time a postback occurs (for some other reason), the captured event is included in the post and can be processed. The TextBox control's Change event is an example of a non-postback event.

Further programmer control is provided by the AutoPostback property, which determines if the control's Change event triggers an immediate postback (AutoPostback=True) or whether the Change event is captured and cached as described above (AutoPostback=False). This property is relevant for the TextBox, ListBox, and CheckBox controls. Be aware that AutoPostback will not work properly if the user disabled scripting in his browser.