• Choose a category
• All
• Classic-Fiction

DataBinding

Occurs when the DataBind method is called on the page to bind all the child controls to their respective data sources

Disposed

Occurs when the page is released from memory, which is the last stage of the page life cycle

Error

Occurs when an unhandled exception is thrown.

Init

Occurs when the page is initialized, which is the first step in the page life cycle

InitComplete

Occurs when all child controls and the page have been initialized

Load

Occurs when the page loads up, after being initialized

LoadComplete

Occurs when the loading of the page is completed and server events have been raised

PreInit

Occurs just before the initialization phase of the page begins

PreLoad

Occurs just before the loading phase of the page begins

PreRender

Occurs when the page is about to render

PreRenderComplete

Occurs just before the pre-rendering phase begins

SaveStateComplete

Occurs when the view state of the page has been saved to the persistence medium

Unload

Occurs when the page is unloaded from memory but not yet disposed of

The Eventing Model

When a page is requested, its class and the server controls it contains are responsible for executing the request and rendering HTML back to the client. The communication between the client and the server is stateless and disconnected because it’s based on the HTTP protocol. Real-world applications, though, need some state to be maintained between successive calls made to the same page. With ASP, and with other server-side development platforms such as Java Server Pages and PHP, the programmer is entirely responsible for persisting the state. In contrast, ASP.NET provides a built-in infrastructure that saves and restores the state of a page in a transparent manner. In this way, and in spite of the underlying stateless protocol, the client experience appears to be that of a continuously executing process. It’s just an illusion, though.

Introducing the View State

The illusion of continuity is created by the view state feature of ASP.NET pages and is based on some assumptions about how the page is designed and works. Also, server-side Web controls play a remarkable role. In brief, before rendering its contents to HTML, the page encodes and stuffs into a persistence medium (typically, a hidden field) all the state information that the page itself and its constituent controls want to save. When the page posts back, the state information is deserialized from the hidden field and used to initialize instances of the server controls declared in the page layout.

The view state is specific to each instance of the page because it is embedded in the HTML. The net effect of this is that controls are initialized with the same values they had the last time the view state was created—that is, the last time the page was rendered to the client. Furthermore, an additional step in the page life cycle merges the persisted state with any updates introduced by client-side actions. When the page executes after a postback, it finds a stateful and up-to-date context just as it is working over a continuous point-to-point connection.

Two basic assumptions are made. The first assumption is that the page always posts to itself and carries its state back and forth. The second assumption is that the server-side controls have to be declared with the runat=server attribute to spring to life when the page posts back.

The Single Form Model

ASP.NET pages are built to support exactly one server-side