Use the following key for the events below:
Black – every time page is processed
Red – only if the request is transacted
Green – only on postback
Blue – only if tracing is enabled
Begin Transaction (only when transactions are enabled for the page) Begin Transaction ProcessRequestTransacted()
Process Request Main
Transactions.InvokeTransacted — parts of the request that need to be done under transacted context Process Request Main (every page, this is the main execution path) Init InitRecursive()
Raise OnInit (recursive)
Begin tracking viewstate LoadViewState LoadPageViewState()
LoadPageStateFromPersistenceMedium() ProcessPostData1 ProcessPostData(_requestValueCollection, true /* BeforeLoad */);
Hand postback data to the controls that exist before Page_Load
Page.Validate() Load LoadRecursive();
Fire OnLoad() (recursive) ProcessPostData2 ProcessPostData(_leftoverPostData, false /* BeforeLoad */);
Hand postback data to controls added in Load (using LoadControl, for example) Raise ChangedEvents RaiseChangedEvents()
RaisePostDataChangedEvent() on each control with postback data that is not an IPostBackEventHandler Raise PostBackEvent RaisePostBackEvent(_requestValueCollection)
RaisePostBackEvent() on the control that caused the postback PreRender PreRenderRecursive()
EnsureChildControls() — creates controls if they haven’t already been created by databinding
Fire OnPreRender (recursive) Build Trace Tree BuildProfileTree("ROOT", EnableViewState) SaveViewState SavePageViewState()
Save state recursively for the page and it’s controls Render RenderControl(CreateHtmlTextWriter(Response.Output))
Render() (recursive) Finish Transaction (only when transactions are enabled for the page) End Transaction Fire OnAbortTransaction() or OnCommitTransaction() End Trace (only when Tracing is enabled) Trace.EndRequest if PageOutput
Trace.Render Process Request Cleanup (every request)
* Set Request and Response to null UnloadRecursive UnloadRecursive()
Fire OnUnload() (recursive)
First, Page Init executes (I’m going to leave out the transaction-related events – you do create a DAL for your data access code, don’t you 😉 ). One good use for this event is for wiring up event handlers. Just be aware that viewstate has not yet loaded.
The next method we’ll talk about is the familiar Page Load event. It is in this event that most of our code that we want to run when the page loads will be placed. At this point ViewState is available and all controls that have been declared on the page have been handed the postback data. Note that if you have controls or user controls on the page, their individual Page_Load events will fire after the page’s Page_Load event, in the order they were added to the control tree. The same is true for other controls events.
The PreRender event fires after the Page_Load events and after any controls events, such as a Button Click event. This is useful for manipulating anything you want, just before the page is rendered. One use is to store member variables in ViewState here to create a “Stateful” web page. To read the ViewState, we would re-hydrate the member variables in the Page Load event. Handling ViewState in this way, keeps the code in one place and creates a consistent state handling mechanism.
Finally, the page is rendered. We can override the Render event in controls to change the behavior of the control (useful for example when creating derived controls that extend the functionality of existing ASP Web Controls).
To give you an example of the execution sequence, here is the sequence from a page with one button and one user control that contains one button. The example shows the execution list after the user has clicked the button on the user control:
Hope this is helpful. I’ll address this in ASP.Net 2.0 in the near future.