Friday, June 13, 2008

4. In what order do the events ofan ASPX page Execute?

Control Execution Lifecycle

The server loads an ASP.NET page every time it is requested and then unloads it after the request is completed. The page and the server controls it contains are responsible for executing the request and rendering HTML back to the client. Although the communication between the client and the server is stateless and disconnected, the client experience must appear to be that of a continuously executing process.

This illusion of continuity is created by the ASP.NET page framework and by the page and its controls. On postback, a control must behave as if it were starting where it left off at the end of the previous Web request. The ASP.NET page framework makes it relatively easy to perform state management, but control developers must be aware of the control execution sequence to achieve the effect of continuity. Control developers need to understand which information is available to a control at each phase in its lifecycle, which data is persisted, and what the control's state is when it is rendered. For example, a control is unable to invoke its parent until the tree of controls on a page has been populated.

The following table provides a high-level overview of the phases in the lifecycle of a control. For details, follow the links in the table.


What a control needs to do

Method or event to override


Initialize settings needed during the lifetime of the incoming Web request.

Init event (OnInit method)

Load view state

At the end of this phase, the ViewState property of a control is automatically populated as described in Maintaining State in a Control. A control can override the default implementation of the LoadViewState method to customize state restoration.

LoadViewState method

Process postback data

Process incoming form data and update properties accordingly. See Processing Postback Data.

Note Only controls that process postback data participate in this phase.

LoadPostData method

(if IPostBackDataHandler is implemented)


Perform actions common to all requests, such as setting up a database query. At this point, server controls in the tree are created and initialized, the state is restored, and form controls reflect client-side data

Load event

(OnLoad method)

Send postback change notifications

Raise change events in response to state changes between the current and previous postbacks.

Note Only controls that raise postback change events participate in this phase.

RaisePostDataChangedEvent method

(if IPostBackDataHandler is implemented)

Handle postback events

Handle the client-side event that caused the postback and raise appropriate events on the server

Note Only controls that process postback events participate in this phase.

RaisePostBackEvent method

(if IPostBackEventHandler is implemented)


Perform any updates before the output is rendered. Any changes made to the state of the control in the prerender phase can be saved, while changes made in the rendering phase are lost

PreRender event

(OnPreRender method)

Save state

The ViewState property of a control is automatically persisted to a string object after this stage. This string object is sent to the client and back as a hidden variable. For improving efficiency, a control can override the SaveViewState method to modify the ViewState property.

SaveViewState method


Generate output to be rendered to the client.

Render method


Perform any final cleanup before the control is torn down. References to expensive resources such as database connections must be released in this phase.

Dispose method


Perform any final cleanup before the control is torn down. Control authors generally perform cleanup in Dispose and do not handle this event.

UnLoad event (On UnLoad method)

No comments: