Loading ...

ASP.NET Page Lifecycle | CodeAsp.Net

ASP.NET Page Lifecycle

(96181)
2.75
/5
Avg: 2.75/5: (4 votes)
Published: 1/12/2012 by Vivek Thakur


Introduction

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.

Background

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.

Basics: 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 (WebForm.aspx.cs) which contains the code for the events and other methods related to a Page, and the designer ASPX file, 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".

Real Thing: 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:

http://msdn2.microsoft.com/en-us/library/1whwt1k7%28VS.80%29.aspx

Below is the sequence of events which fire up sequentially with explanation on the relative importance with respect to web programming in code behind:

Important Note: All events except the Init() and Unload() are fired from outermost to the innermost control. For e.g., a user control’s init event would fire before the Page_Init() event of its parent Page class.

1. PreInit()

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 = “Hello”, 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 and add your custom code:

protected override void OnPreInit(EventArgs e)

{
//custom code

base.OnPreInit(e);
}


Note that PreInit() is the only event where we can set themes programmatically.

Special Case with MasterPages

It is important to note that Master Page is treated like a control in the Content Pages.
So if a Page has a  Master Page associated with it, then the controls on the page will not be initialized and would be null in this stage. Only after the Init() event starts, you can access these controls directly from the page class. Why?

The reason being that all controls placed in the Content Page are within a ContentPlaceholder which is a child control of a MasterPage. Now Master Page is merged and treated like a control in the Content Pages. As I mentioned earlier, all events except the Init() and Unload() are fired from outermost to the innermost control. So PreInit() in the Page is the first event to fire but User Controls or MasterPage (which is itself a Usercontrol) do not have any PreInit event . Therefore in the Page_PreInit() method, neither the MasterPage nor any user control has been initialized and only the controls inside the Page class are set to their default values. Only after the Page_PreInit() event the Init() events of other controls fire up.

See the diagram below showing control hierarchy after the Page_Init() event:



2. OnInit()

In this event, we can read the controls properties (set at design time). We cannot read control values changed by the user because that changed value will get loaded after LoadPostData() event fires. But we can access control values from the forms POST data as:

string selectedValue = Request.Form[controlID].ToString();

3. LoadViewState

 This will only fire if the Page has posted back (IsPostBack == true). Here the runtime de-serializes the view state data from the hidden form element and loads all controls who have view state enabled.

4. LoadPostBackData

Again, this method will only fire if the Page has posted back.
In this event the controls which implement IPostBackDataHandler interface gets loaded by the values from the HTTP POST data. Note that a textbox control does not gets its value from the view state but from the post data in the form in this event. So even if you disable view state for a particular control, it can get its value from the HTTP POST data if it implements IPostBackDataHandler interface.

Also, an important point to note is that if we have a DropDownList control and we have dynamically added some items to it, the runtime cannot load those values unless the view state is enabled (even if the control derives from IPostBackDataHandler). The reason being that HTTP Post data has only one value per control, and the entire value collection is not maintained in the PostData but in view state.

5. Page_Load

This is the most popular method and the first one for all beginner developers to put their code. Beginners may also think that this is the first method which fires for a Page class. This can lead to a lot of confusion which makes understanding the Page lifecycle all the more important.

Note: If the page has any user control, then it's Load method will fire after the Page class's Load method. The reason as explained earlier is the fact that all method except the Init() are fired from the outermost control to the innermost. So after Page_Load(), load methods of all other controls are fired recursively.

6. Control Event Handlers

These are basically event handlers (like Button1_Click()) which are defined for controls in the ASPX markup. Another source of confusion arises when the developer thinks that an event handler like Button_Click() should fire independently (like in windows apps) as soon as he clicks a Button on the web form, forgetting that Page_Load will fire first before any event handlers.

7. PreRender

This event is again recursively fired for each child controls in the Page. If we want to make any changes to control values, this is the last event we have to peform the same.

8. SaveViewState
Here, the ViewState of the controls gets saved in the form's hidden control.

9. Render

In this method all controls are rendered recursively (i.e. Render method of each control is called).

10. Unload

Here you can have the page and controls perform clean-up operations. This event has no relevance besides clean up operations because the Page has already rendered.

Dynamic Controls

Now we have seen the important events in the Page lifecycle, let's focus on how to create and maintain state of dynamically generated controls. Many times we need to generate controls dynamically for specific business use cases. For example, I was managing a famous hotel reservation website project and one of my team members was facing an issue in handling the Reservation screen. There was a TextBox where the user enters the number of
rooms, and based on that value, dynamic usercontrols having a room's detailed info were created at runtime.

The developer complained that although he was able to generate user controls as runtime in a for loop, but was unable to save their state. When I looked into the code, I noticed that the code to generate controls was written in a Button's Click event handler. Now as we dicussed above, event handlers like Button_Click() fire much later than LoadViewState() and LoadPostData(), where the control values get loaded from the view state and form's Post data.

So unless he recreates the controls in the Page_Init() or Pre_Init() methods (which occur before LoadViewState and LoadPostData), the control values modified by the user won't get reloaded next time.

Now, when he put the code in the Page_Init() event, he was unable to get the number of rooms entered by the user in the TextBox (which was a static control). The reason being that in Page_Init(), control values are initilized to their design time default values, and do not reflect the user entered values unless they are loaded from the POST data or the view state, a process which occurs later.

So the only way to access the user entered value in the control is to get the value from the form's POST data. Here is the code:


protected override void OnInit(EventArgs e)

{
//get value of the TextBox from HTTP POST data

string selectedValue ;
if(Request.Form["txtNoOfRooms"] != null)

selectedValue = Request.Form["txtNoOfRooms"].ToString();


//code to create controls dynamically...

...............


base.OnInit(e);
}


Note: Thanks to Mike Banavige of ASP.NET forums, I added this section. If you create a dynamic control in the Page_Load event, and add it to a PlaceHolder or Panel (with view state turned on), then this dynamic control will maintain its state even though it was not created in the Page_Init(). Why?

The reason is the fact that once a control is added to the control tree of the page, TrackViewState() method is responsible for tracking the state. This method gets fired automatically whenever the control is added to the control tree. Due to this reason, any modifications to the control (like adding items etc) should be done *only after* the dynamic control has been added to the control tree of the Page class, else the state would be lost. See the code below:

protected void Page_Load(object sender, EventArgs e)
{
//create a dynamic dropdown


DropDownList d = new DropDownList();

PlaceHolder1.Controls.Add(d); // TrackViewState() gets fired for our dropdown, so state is maintained


if (!IsPostBack)

{

d.Items.Add("test1");
d.Items.Add("test2");

}

}

This will not work:

protected void Page_Load(object sender, EventArgs e) 

{

//create a dynamic dropdown

DropDownList d = new DropDownList();

if (!IsPostBack)

{

d.Items.Add("test1");

d.Items.Add("test2");

}

PlaceHolder1.Controls.Add(d); //"test1" and "test2" values are lost

}

Summary

I have tried to explain relevant events in the Page lifecycle and their importance with some gotchas. I will keep updating this article with more tips and tricks, besides readers are welcome to point out mistakes and suggest corrections and give feedback!

An important thing to remember here is that the entire lifecycle is repeated on every request. The Page class gets re-instantiated and after serving the request gets unloaded. Once we are clear with the sequence of the events, we can structure our code well to suit different use case requirements. 

 

Comments (17)

This is really good! Keep them coming!
2/27/2009
 · 
 
by
Really nice, helped a lot in clearing doubt related to page life cycle
3/27/2009
 · 
 
by
Thanks for suc a nice and helpful article on Page Life Cycle. Keep up sharing your knowledge on ASP.NET :)
4/3/2009
 · 
 
by
good one
4/21/2009
 · 
 
by
Thanks. This article is really good.
8/20/2009
 · 
 
by
Simple precise and clear. Good one.
8/29/2009
 · 
 
by
excellent article for page lifecycle. This cleared a lot of doubt regarding page events and control events of mine...anyways thanks a lot for this sharing.
9/3/2009
 · 
 
by
its really good
9/8/2009
 · 
 
by
Excellent explanation. Hope you mention about the sequence of events if page has user controls. Thanx for the article.
9/13/2009
 · 
 
by
Mukta
Mukta Pundir said:
A Nice article on page Life Cycle with Master pages Mukta Pundir
4/12/2010
 · 
 
by
Mukta
Mukta Pundir said:
Really nice article on Page Life Cycle with master Pages.
4/12/2010
 · 
 
by
naval198409
naval pandey said:
nice
6/29/2012
 · 
 
by
imedsandeep
sandeep kumar said:
Nice Article I realy Like...
7/30/2012
 · 
 
by
akramkhan
Kuvar Akram said:
Easy to understand
9/25/2012
 · 
 
by
anisha
anisha said:
Excellent !..Thanks
1/16/2013
 · 
 
by
jozef
jozef said:
simple and amazing article
1/17/2013
 · 
 
by
dheeraj
Dheeraj Gupta said:
Excellent very knowledgeable...
3/22/2013
 · 
 
by
  • Name:*
  • Email:*
  • Website:
Type the characters you see in the image *

Top articles

Related articles

  • ASP.NET MVC Framework Tutorial

    The Model View Controller (MVC) is a buzzword in the ASP.NET community, thanks to the upcoming ASP.NET MVC Framework that Microsoft has launched recently. The Framework allows easier adoption of the different MVC patterns in our web applications. In this article we will discuss ASP.NET MVC Framework in detail with the help of a Sample Project. We a
    2/5/2009 by Vivek Thakur
  • The Importance of Web Design and Website Credibility

    One of the most significant functions of websites today is to provide credibility for your business. The credibility of your website is becoming more and more an increasingly important area to understand. And it's an area that many web developers and web designers fail to recognize when creating websites.
    2/3/2009 by Tim Eisenhauer
  • Dependency Injection And Factory Design

    Using simple design patterns can help create flexible software which is also easy to maintain and also reduce costs. By the help of this article I wanted to explain how this flexibility can be achieved in real world programs. Also if there are any suggestions on improving this design, I would love to hear them.
    2/3/2009 by Vivek Thakur
  • How to Restore a MSSQL 2005 Database

    Restoring a MSSQL 2005 database can mean problems for those that do not know how to do it properly. Especially if you are restoring this database on a different server than what it was created on. Read how to do it here.
    1/6/2009 by Tim Eisenhauer

Quick Vote

What kind of email newsletter would you prefer to receive from CodeAsp.Net?