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.
|Phase||What a control needs to do||Method or event to override|
|Initialize||Initialize settings needed during the lifetime of the incoming Web request. See Handling Inherited Events.||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.
(if IPostBackDataHandler is implemented)
|Load||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. See Handling Inherited Events.||Load event
|Send postback change notifications||Raise change events in response to state changes between the current and previous postbacks. See Processing Postback Data.
(if IPostBackDataHandler is implemented)
|Handle postback events||Handle the client-side event that caused the postback and raise appropriate events on the server. See Capturing Postback Events.
(if IPostBackEventHandler is implemented)
|Prerender||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. See Handling Inherited Events.||PreRender event
|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. See Maintaining State in a Control.||SaveViewState method|
|Render||Generate output to be rendered to the client. See Rendering an ASP.NET Server Control.||Render method|
|Dispose||Perform any final cleanup before the control is torn down. References to expensive resources such as database connections must be released in this phase. See Methods in ASP.NET Server Controls.||Dispose method|
|Unload||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)|
**Note ** To override an EventName event, override the OnEventName method (and call base. OnEventName).
The methods and events in the third column are inherited from System.Web.UI.Control, with the following exceptions: LoadPostData and RaisePostDataChangedEvent are methods of the IPostBackDataHandler interface, and RaisePostBackEvent belongs to the IPostBackEventHandler interface. If your control participates in postback data processing you must implement IPostBackDataHandler. If your control receives postback events you must implement IPostBackEventHandler.
The CreateChildControls method is not listed in the table because it is called whenever the ASP.NET page framework needs to create the controls tree and this method call is not limited to a specific phase in a control's lifecycle. For example, CreateChildControls can be invoked when loading a page, during data binding, or during rendering.
Capturing Postback Events | Processing Postback Data | Handling Inherited Events | Maintaining State in a Control