Asp.Net Page Life Cycle – an understanding using msdn

Typical page life cycle : Standalone page , with User Control Embedded , As Content Page within Master Page , As when User Control &  Content Page both on Master Page

What can be best source for understanding the page life cycle other than MSDN itself…? I am just going to refer the same and mentioned key points of for simple to understand and remember. Let’s start with Standalone aspx page… Then rest scenarios will be just change in the sequence of the events while getting called.

Typical page life cycle: Standalone page

Page Life Cycle Events with calling sequence

·         PreInit

·         Init

·         InitComplete

·         PreLoad

·         Load

·         Control events

·         LoadComplete

·         PreRender

·         PreRenderComplete

·         SaveStateComplete

·         Render

·         Unload

Along with the events mentioned above, there some methods which are being called before and after the Events to facilitate functionality. Most of the times developers not aware ( don’t care !! ) about these methods other than other than specific cases like setting something before or after the method call or overloading them, so not covered in detailed.

Also please note that some of these methods are called recursively multiple times depending on the content of the page (e.g. postback  or not etc)


When is getting called

Page Methods getting called Before or during this event call


Typical use /Functionality handled by


Raised after the start stage is complete and
before the page initialization stage begins








Check IsPostBack property to determine
whether this is the first time the page is being processed

(If the request is a
postback, the values of the controls have not yet been restored from view
state. If you set a control property at this stage, its value might be
overwritten in the next event.


Typically event is useful for –

Create or re-create dynamic controls ;

Set a master page dynamically.

Set the Theme property dynamically.

Read or set profile property values.



Raised after all controls have been initialized and any skin
settings have been applied




To read or initialize control properties.


The Init event of individual controls
occurs before the Init event of the page.



Raised at the end of the page’s initialization stage.




Only one operation takes place between the Init and InitComplete
events which is tracking of view state changes is turned on.


View state tracking enables controls to persist
any values that are programmatically added to the ViewState collection.


 Until view
state tracking is turned on, any values added to view state are lost across


Controls typically turn on view state tracking
immediately after they raise their Init event.


Use this event to make changes to view state that
you want to make sure are persisted after the next postback.


Raised after the page loads view state for itself and all
controls after it processes postback data that is included with the Request instance.


LoadPageStateFromPersisteceMedium ( Postback Only)


LoadControlState(Postback only)


LoadViewState ( Postback Only)


ProcessPostData ( Postback Only)




only – first try)




The OnPreLoad method is called after all
postback data returned from the user is loaded.


At this stage in the page’s life cycle, view-state
information and postback data for declared controls and controls created
during the initialization stage are loaded into the page’s controls.


Controls created in the OnPreLoad method
will also be loaded with view-state and postback data.


The Page object calls the OnLoad method on the Page object, and then recursively does the same for each
child control until the page and all controls are loaded.


The Load event of individual controls occurs after the Load event of
the page



Use the OnLoad event method to set
properties in controls and to establish database connections.

Control events

TextChanged()  or Click() etc






Use these events to handle specific control
events, such as a Button control’s Click event or a TextBox 
control’s TextChanged event.


In a postback request, if the page contains
validator controls,

Check the IsValid property of the Page and
of individual validation controls before performing any processing.


Raised at the end of the event-handling stage.




Use this event for tasks that require that all
other controls on the page be loaded.


Raised after the Page object has created
all controls that are required in order to render the page, including child
controls of composite controls


The PreRender event of individual
controls occurs after the PreRender event of the page.




Use the event to make final changes to the
contents of the page or its controls before the rendering stage begins.


Raised after each data bound control whose DataSourceID property
is set calls its DataBind method.

Data Binding Events





Raised after view state and control state have been saved for
the page and for all controls







Any changes to the page or controls at this point affect
rendering, but the changes will not be retrieved on the next postback.


It is the processing Stage, not an event, Page
Object call this method on each control. All server controls have a
Render method, which
writes out the control’s markup to send to the






If you create a custom control, you typically override this
method to output the control’s markup.


However, if your custom control incorporates only standard
ASP.NET Web server controls and no custom markup, you do not need to override
 Render method. 

A user control (an .ascx file) automatically incorporates
rendering, so you do not need to explicitly render the control in code


Raised for each control and then for the page.




For Controls – use this event to do final cleanup for specific
controls, such as closing control-specific database connections.


For Page – use this event to do final cleanup work, such as
closing open files and database connections, or finishing up logging or other
request-specific tasks.


During the unload stage, the page and its controls have been
rendered, so you cannot make further changes to the response stream. If you
attempt to call a method such as the Response.Write method,
the page will throw an exception.


For those who don’t know View State Tracking

Control.TrackViewState Method It Causes tracking of view-state changes to the server control so they can be stored in the server control's StateBag object.  This object is accessible through the Control.ViewState property.Use this method when you have to develop template data-bound controls.

This method alerts ASP.NET to monitor changes to a server control's view state, which is required when you override the Control.DataBind method. The control then uses the IsTrackingViewState property to determine whether view-state change tracking is enabled  for the control. If it is not enabled, the TrackViewState method is called.

Ref – MSDN

Some important Event Methods in above Page Life cycle :

LoadControlState(postback only): The page recursively calls the LoadControlState method of those controls in its Controls collections that have called the RegisterRequiresControlState method of the page class to express interest in using their control states.

LoadViewState(postback only): The page first calls its own LoadViewState method and then recursively calls the LoadViewState method of the controls in its Controls collection to allow them to load their saved view states.

LoadPostData(postback only – first try): The page calls the LoadPostData method of the controls that implement the IPostBackDataHandler interface and passes the posted data into it. The LoadPostData method of each control must access the posted data and update the respective property of the control accordingly. For example, the LoadPostData method of the TextBox control assigns the new value of the text box to the Text property of the TextBox control.

LoadPostData(postback only second try): The page calls the LoadPostData method of those controls that where programmatically added to its Controls collection in the Load phase if they implement the IPostBackDataHandler interface.

RaisePostDataChangedEvent(Postback only): The page calls the RaisePostDataChangedEvent method of those controls whose LoadPostData method returned true. The RaisePostDataChangedEvent method raises post data changed event. For example, TextBox control raises this event when the new value of the text box is different from the old value.

RaisePostbackEvent (postback only): The page calls the RaisePostBackEvent method of the control whose associated HTML element submitted the form. For example, the Button control's associated HTML element posts the page back to the server. The RaisePostBackEvent method of a control must map the postback event to one or more server-side events. For example, the RaisePostBackEvent method of the Button control maps the postback event to the Command and Click server-side events.

Overall Page life cycle with the Events & methods

  • PreInit
  • Init
  • InitComplete
  • LoadControlState (Postback only)
  • LoadViewState (Postback only)
  • LoadPostData (Postback only – first try)
  • PreLoad
  • Load
  • LoadPostData (Postback only – second try)
  • RaisePostDataChangedEvent (Postback only)
  • RaisePostbackEvent (Postback only)
  • LoadComplete
  • RaiseCallbackEvent (Postback and Callback only)
  • PreRender
  • PreRenderComplete
  • SaveControlState
  • SameViewState
  • SaveStateComplete
  • Render


Now let’s say we have User Control on the webpage then Page life cycle will be as follows

  • PreInit – Page
  • Init – UserControl
  • Init – Page
  • InitComplete – Page
  • LoadPageStateFromPersistenceMedium – Page 
  • ProcessPostData (first try) – Page
  • PreLoad – Page
  • Load – Page
  • Load – UserControl
  • ProcessPostData (second try) – Page
  • RaiseChangedEvents – Page
  • RaisePostBackEvent – Page
  • Control Events – Page
  • Control Event – UserControl
  • DataBinding – Page
  • DataBinding – UserControl
  • LoadComplete – Page
  • PreRender – Page
  • PreRender – UserControl
  • PreRenderComplete – Page
  • SaveViewState – Page
  • SavePageStateToPersistenceMedium – Page
  • SaveStateComplete – Page
  • Unload – UserControl
  • Unload – Page

Please refer to previous post for the Life Cycle details


There can be the case that you have one Master page in which you web page is content page , in that case LifeCycle will be as follows

  • PreInit – Page
  • Init – MasterPage
  • Init – Page
  • InitComplete – Page
  • LoadPageStateFromPersistenceMedium – Page 
  • LoadControlState (Postback only) – Page
  • LoadViewState (Postback only) – Page
  • ProcessPostData (first try) – Page
  • LoadPostData (Postback only – first try) – Page
  • PreLoad – Page
  • Load – Page
  • Load – MasterPage
  • ProcessPostData (second try) – Page
  • RaiseChangedEvents – Page
  • RaisePostBackEvent – Page
  • Control Events – OnClick,TextChanged,GridView Events  followed by DataBinding
  •     DataBinding – Page
  •     DataBinding – MasterPage
  •     DataBinding – UserControl
  •     DataBinding – ChildUserControl
  • LoadComplete – Page
  • PreRender – Page
  • PreRender – MasterPage
  • PreRenderComplete – Page
  • SaveViewState – Page
  • SavePageStateToPersistenceMedium – Page
  • SaveStateComplete – Page
  • Unload – MasterPage
  • Unload – Page

There is one scenario given by mbanavige on Forums(  I am just going to refer the same ,

Our test setup is composed of a Page, MasterPage, UserControl, Nested UserControl and Button control as follows: The Page is tied to the MasterPage,The UserControl is on the Page,The Nested UserControl is on the UserControl,The Button is on the Nested UserControl.,Clicking the Button calls the Page.DataBind method

Then in above mentioned case page life cycle will be as follows

  • PreInit – Page
  • Init – Nested ChildUserControl
  • Init – UserControl
  • Init – MasterPage
  • Init – Page
  • InitComplete – Page
  • LoadPageStateFromPersistenceMedium – Page 
  • ProcessPostData (first try) – Page
  • PreLoad – Page
  • Load – Page
  • Load – MasterPage
  • Load – UserControl
  • Load – Nested ChildUserControl
  • ProcessPostData (second try) – Page
  • RaiseChangedEvents – Page
  • RaisePostBackEvent – Page
  • Click – Button – Nested ChildUserControl
  •    DataBinding – Page
  •    DataBinding – MasterPage
  •    DataBinding – UserControl
  •    DataBinding – Nested ChildUserControl
  • LoadComplete – Page
  • PreRender – Page
  • PreRender – MasterPage
  • PreRender – UserControl
  • PreRender – Nested ChildUserControl
  • PreRenderComplete – Page
  • SaveViewState – Page
  • SavePageStateToPersistenceMedium – Page
  • SaveStateComplete – Page
  • Unload – Nested ChildUserControl
  • Unload – UserControl
  • Unload – MasterPage
  • Unload – Page


Interview quickies:

1)    If we have a page called "Default" and a Master page called "DefaultMaster".
Both contain Page Load events. When a page request comes to Default page, which Page Load event will call first

Ans : Default.aspx Page load


2)    If we have a page called "Default" and a Master page called "DefaultMaster".
For both Page.Init events is handled. When a page request comes to Default page, which Page Init () event will call first


Ans:- DefaultMaster.Master page init event followed by Default.aspx

In Case of Nested Master Pages –

Main Master Page Init ===> Nested/Sub Master page Init ===>

Content Page Init /Requester Page.aspx


If you are still unsatisfied with life cycle events

Reference :


Typed DataSet and Untyped DataSet

It’s been Long time since I used Typed Datasets, so just wanted refresh the basics differences between ‘Ordinary’ and Typed Datasets


Typed DataSet :


  • A typed DataSet is a class that derives from a DataSet. As such, it inherits all the methods, events, and properties of a DataSet. Additionally, a typed DataSet provides strongly typed methods, events, and properties.


  • The typed dataset is binded with the database tables(s) at design time and you have all the schema information at design time in your code. It is added as .xsd file in your application.


  •  This means you can access tables and columns by name, instead of using collection-based methods. 


  •  Aside from the improved readability of the code, a typed DataSet also allows the Visual Studio .NET code editor to automatically complete lines as you type.


  •  Additionally, the strongly typed DataSet provides access to values as the correct type at compile time. With a strongly typed DataSet, type mismatch errors are caught when the code is compiled rather than at run time.


  •  Access to tables and columns in a typed dataset is also slightly faster at run time because access is determined at compile time, not through collections at run time.


 UnTyped DataSet :

  •  Untyped dataset is an object of class System.Data.DataSet.
  • It is binded with the tables at runtime.
  • You are not aware of the schema of the dataset at design time. There are a variety of circumstances under which an untyped dataset is useful. The most obvious scenario is that no schema is available for the dataset. This might occur, for example, if your application is interacting with a component that returns a dataset, but you do not know in advance what its structure is. Similarly, there are times when you are working with data that does not have a static, predictable structure; in that case, it is impractical to use a typed dataset, because you would have to regenerate the typed dataset class with each change in the data structure.
  • You can access the tables and columns using index no.
  • More generally, there are many times when you might create a dataset dynamically without having a schema available. In that case, the dataset is simply a convenient structure in which you can keep information, as long as the data can be represented in a relational way.
  • At the same time, you can take advantage of the dataset’s capabilities, such as the ability to serialize the information to pass to another process, or to write out an XML file


// This accesses the Name column in the first row of the Employee table.

string s = dsEmployee.Employee[0].Name;

The same call using the UnTyped Dataset as follows

string s = (string) dsEmployee.Tables[“Employee “].Rows[0][“Name”];

Useful References –



%d bloggers like this: