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
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'm making an ASP.NET application that performs some globalization in the Render event of the Master Page. Basically my code uses regular expressions to look for placeholders (text patterns, not actual PlaceHolder controls) in the markup and replaces them with the corresponding translations found in an XML file.
This works as intended when the page is loaded normally, but on a partial postback the Render event does not seem to trigger at all for the Master Page, leaving the rendered page full of placeholders. The event does trigger for the current Page however, but I don't want to alter the output HTML separately in every single page's Render event.
The ContentPlaceHolder (containing the current Page) of the Master Page is located inside an UpdatePanel, and I assume this has something to do with what is happening. I still don't understand why the event is not triggered, however.
Is there a way to force the Master Page Render event to trigger on partial postback, or should I consider a different solution?
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 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.