| Just as you'll find when working with Windows Forms, ASP.NET Web Forms raise events in a certain order as the page initializes and loads. ASP.NET also raises events in response to user interaction in the browser. When you think about how a standard ASP or HTML page is created and sent to a browser, you assume that everything is processed in a very linear, top-down fashion. However, for a Web Form, nothing could be further from the truth. Like a Windows Form, a Web Form goes through the standard Load, Draw (Render), and Unload types of events. Throughout this process, different procedures within the page's class module are called. When a page is requested from a client browser, a DLL that encapsulates the tags in the ASPX page as well as the page code is loaded and then processed. First, the Init event occurs as ASP.NET sets the page to its initial state, as described by the tags in the ASPX file. If the page is posting back to itself, Init also restores any page state that may have been stored by the page previously. Next, ASP.NET raises the Load event as the page is loaded. In the event handler for this event, you can use the Page.IsPostback property to determine whether the page has posted back to itself. This might happen because a user has clicked a button or is interacting with some other control that caused a postback to the page. You might perform some initialization only on the first page load for example, you might bind data into the controls. (You're far more likely to trigger a postback with ASP.NET pages than you are when creating ASP applications. Because ASP.NET makes it so simple to have just about any control passed back to the page and to run event code before the page renders again, you'll find that you end up running code in the Page_Load procedure quite often. Checking the Page.IsPostback property will allow you to only run code the first time the page is loaded, if that makes sense.) Next, if the page is being posted back, ASP.NET raises control events. (If the page isn't being posted back that is, being loaded for the first time event procedures won't run. There's obviously no event that requires handling yet.) First, all the "change" events are fired. These events are batched up in the browser and executed only when the page is sent back to the server. These "change" events include changing the text in a text box and selecting an item in a ListBox or DropDownList control. TIP Event procedures only run when you post back to a page. Postback happens immediately, and automatically, when you click a button. You may want to have postback occur automatically when you select an item from a list or when you check a check box. Doing this in ASP requires you to write client-side script. In ASP.NET, it's as simple as setting a control's AutoPostBack property to True. When you do that, ASP.NET inserts the appropriate client-side script for you, so clicking the check box or selecting an item from a list triggers a postback, and the page can run the associated event code immediately.
TIP You cannot control the order in which the "change" events fire on the server. You are guaranteed only that they will all fire.
Next, and only if the page is posted back, the control event that caused the page to post back is fired. Examples of postback events include a button's Click event or controls for which you've set the AutoPostBack property to True, like a check box's CheckedChanged event. Next, the page is rendered to the browser. Some state information (the page's view state) is included in a hidden field in the page so that when the page is called again through a postback, ASP.NET can restore the page to its previous state. (You'll learn more about view state and managing state in Chapter 23, "State Management in ASP.NET.") There is a final page event your code can handle before the page is disposed: the Unload event. Because the page is already rendered, this event is typically used to perform cleanup and logging tasks only. Finally, the class that represents the running page is removed from memory, and the page is unloaded from memory as well. If you change the ASPX page or its code, the dynamically generated DLL that represents the page will be regenerated the next time the page is requested. This DLL is stored to disk each time it is generated. | 
