| ViewState vs Session |
| gagan kopparam posted at Thursday, February 14, 2008 3:28 PM |
i see this using vs 2005, master page and its content page, the view state is not updated automatically as expected on post back.
at what stage in the life sycly can i access the controls on the master page from the child page
thanks |
 |
|
|
| |
| Both master pages and content pages can contain event handlers for controls. |
| Peter Bromberg replied to gagan kopparam at Thursday, February 14, 2008 3:38 PM |
 |
For controls, events are handled locally—a control in a content page raises an event in the content page, and a control in the master page raises an event in the master page. Controls events are not sent from the content page to the master page. Similarly, you cannot handle an event from a master page control in a content page.
In some cases, the same event is raised in both the content and the master page. For example, both pages raise Init and Load events. The general rule for how events are raised is that the initialization events are raised from the innermost control to the outermost one, and all other events are raised from the outermost control to the innermost one. It is helpful to remember that the master page is merged into the content page and treated as a control in the content page, which you can access via the Page's Master property.
The following is the order in which events occur when the master page is merged with a content page:
-
Master page controls Init event.
-
Content controls Init event.
-
Master page Init event.
-
Content page Init event.
-
Content page Load event.
-
Master page Load event.
-
Content controls Load event.
-
Content page PreRender event.
-
Master page PreRender event.
-
Master page controls PreRender event.
-
Content controls PreRender event.
So, to answer your question, you can access the controls on the MasterPage from the child page safely once the MasterPage Load event has fired.
You can write code in content pages that references properties, methods, and controls in the master page, with some restrictions. The rule for properties and methods is that you can reference them if they are declared as public members of the master page. This includes public properties and public methods. You can reference controls on the master page independently of referencing public members.
To do this:
1. Add a Mastertype: <%@ MasterType virtualpath="~/Masters/Master1.master" %> 2.Write code that uses the master page's public member as a member of the Master property, as in this example, which assigns the value of a public property named CompanyName from the master page to a text box on the content page: CompanyName.Text = Master.CompanyName;
|
|
| |
 ViewState vs Session |
| egg egg replied to gagan kopparam at Saturday, March 01, 2008 11:25 AM |
Understanding the lifecycle of a page/control in ASP.NET 1+
was paramount to writing good, clean code - not to mention the steep
decline in frustrating programming sessions. If you do not learn the
page lifecycle, including what the events do, as well as the sequence
in which they occur, you will indeed get mad and sad. Crying may occur.
In
ASP.NET 1+, there were about 8 methods/events that were important to
understand (about 12+ if you are a control developer). In ASP.NET 2.0,
this has been increased significantly to give the developer more
opportunities to inject logic at different points of the page's life.
As
I attempted to locate a good source for the new page lifecycle, I found
incomplete and beta lists, which were typically out of date. I've
compiled a list of events/methods that occur during a typical page
request with as much data as I could find. Most of the method
descriptions are from MSDN2.
| Method
| Postback |
Control |
| Constructor |
Always |
All |
|
| Construct |
Always |
Page |
|
| TestDeviceFilter |
|
Page |
|
Used to determine which device filter is in place, and use this information to decide how to display the page.
|
|
| AddParsedSubObject |
Always |
All |
|
Notifies the server control that an element, either XML or HTML, was
parsed, and adds the element to the server control's ControlCollection
object. |
|
| DeterminePostBackMode |
Always |
Page |
|
Returns a NameValueCollection object that contains the data posted back
to the page. The presence of the page hidden fields VIEWSTATE and
EVENTTARGET is used to help determine whether a postback event has
occurred. The IsPostBack property is set when the DeterminePostBackMode
method is called. |
|
| OnPreInit |
Always |
Page |
|
Called at the beginning of the page initialization stage. After the
OnPreInit method is called, personalization information is loaded and
the page theme, if any, is initialized. This is also the preferred
stage to dynamically define a PageTheme or MasterPage for the Page. |
|
| OnInit |
Always |
All |
|
Performs the initialization and setup steps required to create a Page
instance. In this stage of the page's life cycle, declared server
controls on the page are initialized to their default state; however,
the view state of each control is not yet populated. A control on the
page cannot access other server controls on the page during the
Page_Init phase, regardless of whether the other controls are child or
parent controls. Other server controls are not guaranteed to be created
and ready for access. |
|
| OnInitComplete |
Always |
Page |
|
Called after page initialization is complete. In this stage of the
page's life cycle, all declared controls on the page are initialized,
but the page's view state is not yet populated. You can access server
controls, but they will not yet contain information returned from the
user. |
|
| LoadPageStateFromPersistenceMedium |
Postback |
Page |
|
Uses the Load method of the System.Web.UI.PageStatePersister object
referenced by the PageStatePersister property to load any saved
view-state information for the Page object. |
|
| LoadControlState |
Postback |
All |
|
Restores control-state information from a previous page request that was saved by the SaveControlState method.
|
|
| LoadViewState |
Postback |
All |
|
Restores view-state information from a previous page request that was saved by the SaveViewState method.
|
|
| OnPreLoad |
Always |
Page |
|
Called after all postback data returned from the user is loaded. At
this stage in the page's life cycle, view-state information and
postback data for declared controls and controls created during the
initialization stage are loaded into the page's controls. Controls
created in the OnPreLoad method will also be loaded with view-state and
postback data. |
|
| OnLoad |
Always |
All |
|
Notifies the server control that it should perform actions common to
each HTTP request for the page it is associated with, such as setting
up a database query. At this stage in the page lifecycle, server
controls in the hierarchy are created and initialized, view state is
restored, and form controls reflect client-side data. |
|
| RaisePostBackEvent |
Postback |
All |
|
Notifies the server control that caused the postback that it should handle an incoming postback event.
|
|
| OnLoadComplete |
Always |
Page |
| At this point in the page life cycle, all postback data and view-state data is loaded into controls on the page.
|
|
| OnPreRender |
Always |
All |
|
Notifies the server control to perform any necessary prerendering steps
prior to saving view state and rendering content. |
|
| OnPreRenderComplete |
Always |
Page |
|
At this stage of the page life cycle, all controls are created and the
page is ready to render the output. This is the last event called
before the page's view state is saved. |
|
| SaveControlState |
Always |
All |
|
Saves any server control state changes that have occurred since the
time the page was posted back to the server. If there is no state
associated with the control, this method returns a null reference.
Custom controls using control state must call the
RegisterRequiresControlState method on the Page before saving control
state. |
|
| SaveViewState |
Always |
All |
|
Saves any server control view-state changes that have occurred since
the time the page was posted back to the server. If there is no view
state associated with the control, this method returns a null
reference. |
|
| SavePageStateToPersistenceMedium |
Always |
Page |
|
Saves any view-state and control-state information for the page. The
SavePageStateToPersistenceMedium method uses the Save method of the
System.Web.UI.PageStatePersister object referenced by the
PageStatePersister property to store view-state and control-state
information for the page. |
|
| Render |
Always |
All |
|
Initializes the HtmlTextWriter object and calls on the child controls
of the Page to render. The Render method is responsible for creating
the text and markup that is sent to the client browser. The default
Render method calls RenderChildren to write the text and markup for the
controls contained on the page. |
|
| OnUnload |
Always |
All |
|
Used to do target-specific processing in the Unload stage of the
control lifecycle. Typically, these are cleanup functions that precede
disposition of the control. |
|
|
| |
|
|