Understanding Page lifecycle is very crucial in order to develop ASP.NET applications. Most beginners tend to get confused while dealing with “dynamic controls” and face problems like losing values, state etc on postbacks. Since HTTP is stateless, the nature of web programming is inherently different from windows application development, and the Page lifecycle is one of the primary building blocks while learning ASP.NET. The sequence of events, especially while working with MasterPages in ASP.NET 2.0, has become slightly more complex and this article is aims to shed some light on these events by explaining the order and importance of each event.
Whenever the user requests a particular “.aspx” page in an application, a lot of interesting things happen on the web server where the application is hosted. Understanding this sequence of events will help us to program and respond to events properly and also clear any confusion which generally arises due to the stateless nature of web programming.
The New Compilation Model and the Partial Classes
Each web form in an ASP.NET application derives directly or indirectly from a “System.Web.UI.Page” class. A web form has two components: a code behind file (Default.aspx.cs) which contains the code for the events and other methods related to a Page, and the designer ASPX file(Default.aspx), which contains HTML control declarations and events (in the Visual Studio 2005 Web Application project model, we have a designer class named WebForm.aspx.designer.cs).
In ASP.NET 2.0, we do not need to define the control variables as well as there event handlers in the code behind, thanks to Partial classes. In ASP.NET 1.x, all this code was auto generated and placed in the code behind file under InitializeComponent() section. But in version 2.0, the runtime will create a partial class dynamically from the ASPX page containing all this info and merge it with the code behind partial class. This will help in making the actual code behind class a lot cleaner and more manageable.
Also, this would eliminate the name change related issues which were common in VS 2003 (if we change any control’s ID, it had to be changed everywhere and VS used to modify the code many times). All control related events are defined in the ASPX markup code. So having a single place for controls names and event handlers is cleaner and flexible, whereas the previous VS 2003 model was more “brittle”.
The Page life cycle
It is very important to know that for each request, the Page class is instantiated everytime from “scratch”. Which means that any values or whatever state it had previously will get lost unless we use one of the various state maintainance mechanisms provided by ASP.NET like Application, Session, Cache variables or Cookies.
Side Note: View state in ASP.NET 2.0 has changed and now comprises of two parts: Control State and View state. Refer this article for details.
Below is the sequence of events which fire up sequentially with explanation on the relative importance with respect to web programming in code behind:
In this Page level event, all controls created during design time are initialized with their default values. For e.g., if you have a TextBox control with Text property = “ShivaSoft”, it would be set by now. We can create dynamic controls here.
This event occurs only for the Page class and “UserControls / MasterPages do not have this method to override“.
Sample code where you can override this method :
protected override void OnPreInit(EventArgs e)
Note that PreInit() is the only event where we can set themes programmatically.