This blog is moved to

Monday, June 15, 2009

The Page Life Cycle Events

As ASP.NET processes a page through its stages, various events are raised for the page and its related controls. You write code to handle these events and thus respond to various actions related to the processing of a page. For example, you might wish to write code that gets called when a page is first loaded to determine if the user is requesting the page or posting back to the server. This is a common scenario. When a page is first requested you often have to initialize data and controls. However, when it posts back you do not wish to run this code. Another common example is when a user clicks a button. You want to respond to the click event for that button only. Knowing which events are called in what order is important to making sure your code executes properly and can be debugged. Table 2-1 contains an ordered list of the more common events that are triggered when a page is processed by ASP.NET.

Event Description

This is the first real event you might handle for a page. You typically use this event only if you need to dynamically (from code) set values such as master page or theme.

This event is also useful when you are working with dynamically created controls for a page. You want to create the controls inside this event.


This event fires after each control has been initialized. You can use
this event to change initialization values for controls.


Raised once all initializations of the page and its controls have been completed.

PreLoad This event fires before view state has been loaded for the page and its controls and before PostBack processing. This event is useful when you need to write code after the page is initialized but before the view state has been wired back up to the controls.

The page is stable at this time; it has been initialized and its state has been reconstructed. Code inside the page load event typically checks for PostBack and then sets control properties appropriately.

The page’s load event is called first. Then, the load event for each child control is called in turn (and their child controls, if any). This is important to know if you are writing your own user or custom controls.

Control (PostBack) event(s) ASP.NET now calls any events on the page or its controls that caused the PostBack to occur. This might be a button’s click event, for example.
LoadComplete At this point all controls are loaded. If you need to do additional processing at this time you can do so here.
PreRender Allows final changes to the page or its control. This event takes place after all regular PostBack events have taken place. This event takes place before saving ViewState, so any changes made here are saved.

Prior to this event the view state for the page and its controls is set. Any changes to the page’s controls at this point or beyond are ignored. This is useful if you need to write processing that requires the view state to be set.


This is a method of the page object and its controls (and not an event). At this point, ASP.NET calls this method on each of the
page’s controls to get its output.
The Render method generates the client-side HTML, Dynamic Hypertext Markup Language (DHTML), and script that are necessary to properly display a control at the browser. This method is useful if you are writing your own custom control. You override this method to control output for the control.


This event is used for cleanup code. You use it to release any managed resources in this stage. Managed resources are resources
that are handled by the runtime, such as instances of classes created by the .NET common language runtime.

No comments: