Page Event
|
Typical Use
|
Raised after the start stage is complete and before the initialization
stage begins.
|
|
Use this event for the following:
|
|
Check the IsPostBack property to determine whether this is
the first time the page is being processed.
The IsCallback andIsCrossPagePostBack properties have also
been set at this time.
|
|
Create or re-create dynamic controls.
|
|
Set a master page dynamically.
|
|
Read or set profile property values.
|
|
Raised after all controls have been initialized and any skin settings
have been applied. The Init event of individual controls occurs
before the Initevent of the page.
|
|
Use this event to read or initialize control properties.
|
|
Raised at the end of the page's initialization stage. Only one
operation takes place between
the Init and InitComplete events: 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 postbacks. 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.
|
|
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.
|
|
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. (To do this, the Page object
calls EnsureChildControls for each control and for the page.)
|
|
The Page object raises the PreRender event on
the Page object, and then recursively does the same for each child
control. 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. For more information, see Data Binding
Events for Data-Bound Controls later in this topic.
|
|
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.
|
|
This is not an event; instead, at this stage of processing,
the Page object calls this method on each control. All ASP.NET Web
server controls have aRender method that writes out the control's markup
to send to the browser.
|
|
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 the Render method. For more information,
seeDeveloping Custom ASP.NET Server Controls.
|
|
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.
|
|
In controls, use this event to do final cleanup for specific controls,
such as closing control-specific database connections.
|
|
For the page itself, 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.
|
|
Source Collected from MSDN
No comments :
Post a Comment