IN THIS CHAPTER, we explore the intricacies of working with server control events. The first part of this chapter is a general discussion of the .NET event architecture. We discuss how to add events to a control, bringing back our favorite Textbox control as part of the demonstration. Then we illustrate how to define custom events and add them to yet another version of our famous Textbox. We also examine System.Web.UI.Control's support for maintaining events. Next, we show how to initiate and capture a postback using a Button control that we create named SuperButton. This section examines Command events and event bubbling with an example composite control to demonstrate these concepts. In the final portion of the chapter, we bring it all together with a discussion of the page life cycle, focusing on events. The next section provides an overview of events and ASP.NET controls. Events and ASP.NET Controls The event-based development paradigm is a well-traveled path on the Windows platform with Visual Basic 6.0 and Visual C++ Microsoft Foundation Classes (MFC) development tools. In this model, developers need not be concerned with the details of how to gather input from hardware or render output to the video card; instead, they can focus on business logic coded in event handlers attached to UI widgets that receive events from the operating system. In ASP.NET, this development model is brought to the Web in much the same way through server controls. The key technology that sets ASP.NET apart from previous web development paradigms is the use of server-side controls as first-class objects in a similar fashion to Visual Basic or MFC. Server controls provide a rich, object-oriented method of building web content in an environment that is normally spartan in its feature set and procedural in its execution model. A critical aspect of working with objects such as ASP.NET server controls is event-based programming, which we cover in this chapter. The Need for Events in ASP.NET In any object-oriented development framework, events are a necessary means of decoupling reusable functionality from the specifics of any given application. This is true in ASP.NET as well. Events allow the encapsulated functionality of a server control, such as a Button, to be hooked into the logic of an application without requiring any changes, such as recompilation, to the UI object. Events simplify the work of the programmer by providing a consistent protocol for development. Client applications can register their interest in a control via an event and be notified later by the control when some activity has taken place in the same way regardless of the control. The only thing that changes from control to control is the number or type of events that are available as well as possibly the arguments that a particular event makes available in its method signature. Figure 5-1 presents a comparison between traditional programming and event-based programming. Figure 5-1. Traditional programming versus event-based programmingASP.NET turns on its head the traditional assumption that UI controls are only appropriate for thick-client applications. Through clever use of client-side state and the HTTP POST protocol, ASP.NET server controls appear as if they maintain memory on the client and react to user interaction by raising events. Server controls do this without having to resort to a bunch of client-side tricks such as applets or ActiveX controls. Even browsing devices that don't support JavaScript on the client can raise events through HTML form actions. Figure 5-2 illustrates how a control can raise events and make it look like ASP.NET has turned the browser into an interactive thick-client application. The TextBox exposes the TextChanged event, while the Button notifies interested clients through a Click event. All event-handling code for the TextChanged and Click events is located on the server where the ASP.NET processing occurs. For the event code to react to changes the user makes with the TextBox on the Web Form in the browser, the control must shift execution from the browser back to the web server. The Button control is responsible for handling this by generating a form postback when it is clicked. Figure 5-2. Server-side control events in ASP.NETButtons automatically generate a form postback, but other server controls can also generate a post back using JavaScript. Changing the AutoPostBack property for a control from the default value of false to true will cause the control to emit the appropriate JavaScript, taking advantage of client-side events to cause postback. When a user clicks a Button in a Web Form and the browser performs an HTTP POST back to the web server, ASP.NET builds the page control tree on the server to dynamically handle the post back request. As discussed in Chapter 4, ASP.NET gives each control in the control tree that has View State enabled a chance to examine posted data through its LoadPostData method. In this method, the control can examine the user input on the server via the posted data and compare it to what was previously stored in ViewState. If the data has indeed changed, and if the control has an event that can be fired in response to the data change, the control should return true to ASP.NET in LoadPostData. Later on in the page life cycle, ASP.NET will call the RaisePostDataChangedEvent member for each server control that returned true in LoadPostData so that the control can in turn raise the appropriate event and execute any business logic implemented via an event handler written by the developer. This is the ASP.NET page life cycle that repeats during each post back for state (data) changes and event firing. Before we dive into writing events for ASP.NET, we first provide a high level overview of events in the .NET Framework in the next section. The .NET Framework Event Model Events are generally used in UI development to notify the appropriate object that the user has made a selection, but events can be used for any asynchronous communication need. Whether you're developing desktop Windows applications using Windows Forms or web applications using ASP.NET, classes as objects need a mechanism to communicate with each other. The .NET Framework provides a first-class event model based on delegates, which we discuss in this section.