I cretated my own server control (a dropdownlist) and thus my own LoadViewState and SaveViewState methods. When is the LoadViewState called? I added the control to my page and looked when the methods are called. Only the SaveViewState is called when the page is requested, LoadViewState is not. Do I have to call it manually?
Thanks :)
The diagram on this MSDN page of the ASP.NET page lifecycle is an excellent reference to have on-hand for these sorts of questions (it's printed out and taped on my cube wall right now).
As you'll see on the diagram, LoadViewState for a control is called after the page's Init, and before the page's PreLoad; it is called only on postback, not on initial page load.
A control's SaveViewState is called after the page's PreRenderComplete, but before the actual Render.
After Init, but before Load. LoadViewState does not run on the initial page load, but subsequent page loads. No need to when no state exists. No you do not need to call manually. You just need to worry about the data you want to save, and reloading that data during the loading phase.
Related
Why we set master page in Page_Init event. We have other events in page.
For me one reason could be that master page does not have Pre_Init and other could be that Init of Page occurs before master page Init. Correct me if I'm wrong.
Master page is a UserControl. During Page.Init event, all the controls on the page are initialized(Control.Init is called). That's why the master page needs to be applied in Page.PreInit
Masterpage doesn't have PreInit method.
Master pages inherits:**System.Web.UI.MasterPage** and as per the design of this MasterPage class no such PreInit event is defined for this class.
Master pages are derived from Control class as seen in below hierarchy:
System.Object
System.Web.UI.Control
System.Web.UI.TemplateControl
System.Web.UI.UserControl
System.Web.UI.MasterPage
Therefore as can be guessed now, Master pages behave and in essence are treated like a control and have events similar to other asp.net server control
Because all things that 'dynamically' modify page controls have to occur there. This is where the page is rebuilt (form objects) with out request. Then things like page_load occur, after all objects are made.
Winforms analogy - if you are familiar with that - page_init is analogous to the InitializeComponent in the New (NOT REALLY SAME - just analogy please).
Only due to the nature of the web (at least round-tripping to the server), it can't possibly work like winforms (or WPF or even a SPA web app with a js/DOM UI and webapi backend) so has to rebuild the form's objects EVERY request.
Why does only the PAGE have page_init and not master page? Well as prateek says, but in addition, the rebuild of the page has to be control from just one spot. There is just one request. Controls can init, too as the page init process calls them in turn.
You have asked a question with a complicated answer.
Here is a good chart of what's going on...
http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx
(source: codeproject.com)
Note how the postback data is loaded into the controls BEFORE the page_load, too - this is why it's too late to do anything big in the page load. You can't possibility get anything back from the user that was changed there (unless you go right to the postback data). The picture shows how ASP tries to 'fake' an event - driven UI on a client/server web architecture (e.g., 'event related logic' calls your 'events'). There is no such thing in client/server asp UI!
As a master page is the default screen throught the application ,it should be initialized first before the child pages.In order to get initalized earlier it is done in pre_init where the master page is loaded.later in Init() all the child pages are loaded regarding to that master page.
During the ASP.NET page life cycle, the initialization is also included on the master page. This is where the design and all the controls that are on the master page will be available before the page is loaded, which will be the "Load" phase of the page life cycle. If the master page is not initialize, you would get a page with no design, except the information on the page.
"During page initialization, controls on the page are available and each control's UniqueID property is set. A master page and themes are also applied to the page if applicable. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state."
https://msdn.microsoft.com/en-us/library/ms178472.aspx
I have Implemented the Globalization in my Page. I have specified the Flags for changing one language to another.
When I click the Flag I am setting the Application["LangId"]="1"; Now the content of the master page is refreshing but the content of the child page does not refresh. Because I have called setting the Language in every child Page load. According to the terminology Child page load fires first and after Master page load and the Click event. If I call the Language setting method in click event I will get the refreshed content.
My question is how we can call the child page method in master page button click event.
You can define a property in your master.
public flag{get;set;}
And load it in page load. Then you can access that from child pages like this:
var flag=((MasterPage)Master).flag;
If you load your child pages this way, they will be refreshed whenever that property changes on MasterPage (if page is refreshed of course)
To understand ASP.NET page life cycle, I believe understanding Page.ProcessRequest method is more important because ProcessRequest method calls all events and methods for a page.
Does anyone know at code level how event and methods calls are arranged in Page.ProcessRequest method (reflector code will also do)?
I believe you are looking for the below order of methods that get runs from ProcessRequest
The processRequest() method cycles through the page's life cycle in the order listed below.
Methods Description
Page_Init Page Initialization
LoadViewState View State Loading
LoadPostData Postback Data Processing
Page_Load Page Loading
RaisePostDataChangedEvent PostBack Change Notification
RaisePostBackEvent PostBack Event Handling
Page_PreRender Page Pre Rendering Phase
SaveViewState View State Saving
Page_Render Page Rendering
Page_Unload Page Unloading
For more information please see on link http://www.dotnettutorials.com/tutorials/performance/page-life-cycle-asp.aspx
I would assume this is true, but wanted to throw this question up. Is the master page executed first in ASP.NET, or does the page which is getting retrieved?
I am asking because I want some processing to be done in the master page, results of which are loaded into a static object and which can then be used by the called page (for instance user data)
Sorry for just quoting, but i don't know what to add:
Individual ASP.NET server controls have their own life cycle that is
similar to the page life cycle. For example, a control's Init and Load
events occur during the corresponding page events.
Although both Init and Load recursively occur on each control, they
happen in reverse order. The Init event (and also the Unload event)
for each child control occur before the corresponding event is raised
for its container (bottom-up). However the Load event for a container
occurs before the Load events for its child controls (top-down).
Master pages behave like child controls on a page: the master page
Init event occurs before the page Init and Load events, and the master
page Load event occurs after the page Init and Load events.
http://msdn.microsoft.com/en-us/library/ms178472.aspx
Execution Priority
Content Page
Master Page
User Control
Most page events will get called before the corresponding ones on the master page are (in essence the master page is considered a part of the page it is linked to - it is a user control).
See ASP.Net 2.0 - Master Pages: Tips, Tricks, and Traps on OdeToCode for details.
you could look at the .net documentation which states when and in what order events are called
see this, this and this
Say I have 5 buttons on a page, numbered 1-5.
When one is clicked, a value with a viewtate getter/setter assigns this the value of the button clicked.
If I am checking for a value in Page_Init() / OnInit(), after the postback has occured, the value will always be empty/null.
Is this correct?
If so, is there anything else I can do that doesnt require an architectural change? Or something similar I can use to persist changes across post backs (Session[] no good unfortunately).
ViewState stores the state of the page (page and control settings + custom values stored in ViewState) between post backs. It is just hidden field with serialized (and encrypted) state data. When you set something to ViewState in code behind it is transfered with page markup to the client and posted back to the sever in the next Postback. The page life cycle (between InitComplete and PreLoad) deserializes state from ViewState. That is the reason why you can't access data from ViewState in OnInit.
refer to :http://code.google.com/p/citiport2/wiki/All_Events
Page: AddParsedSubObject
Page: CreateControlCollection
Page: AddedControl
Page: AddParsedSubObject
Page: AddedControl
Page: ResolveAdapter
Page: DeterminePostBackMode
Page: PreInit
Control: ResolveAdapter
Control: Init
Control: TrackViewState
Page: Init
Page: TrackViewState
Page: InitComplete
Page: LoadPageStateFromPersistenceMedium
Control: LoadViewState
Page: EnsureChildControls
Page: CreateChildControls
Page: PreLoad
Page: Load
Control: DataBind
Control: Load
Page: EnsureChildControls
Page: LoadComplete
Page: EnsureChildControls
Page: PreRender
Control: EnsureChildControls
Control: PreRender
Page: PreRenderComplete
Page: SaveViewState
Control: SaveViewState
Page: SaveViewState
Control: SaveViewState
Page: SavePageStateToPersistenceMedium
Page: SaveStateComplete
Page: CreateHtmlTextWriter
Page: RenderControl
Page: Render
Page: RenderChildren
Control: RenderControl
Page: VerifyRenderingInServerForm
Page: CreateHtmlTextWriter
Control: Unload
Control: Dispose
Page: Unload
Page: Dispose
Page: Init is earlier
I'm not 100% sure what you're asking here, but it sounds like a problem with the ASP.NET Page Lifecycle. It trips up everyone!
Basically, what happens is that a developer expects to be able to do some work in Page_Init (or more commonly Page_Load), but the click event for whatever triggered the postback hasn't happened yet.
In fact, iirc ViewState hasn't even been deserialized when Page_Init fires.
I can't tell you where the right place to do whatever work needs done is without knowing more, but you probably want to move some of that code that's in Page_Init into an event handler later in the lifecycle.
You can see this for yourself: Pop a breakpoint at the start of Page_Init, and another one at the start of MyButton_Click, you'll see that Page_Init fires first.
You can use Request.Form["idofbutton"] to get the posted value. This happens as part of the http protocol. Inspect the http request/ response in something like firebug to see what is getting posted.