PreInit The entry point of the page life cycle is the pre-initialization phase called “PreInit”. This is the only event where programmatic access to master pages and themes is allowed. You can dynamically set the values of master pages and themes in this event. You can also dynamically create controls in this event.
But this definition is valid for other events like load init etc. Correct?
I meant, this job can be done in other events as well.
Query What's the unique meaning of PreInit ?
Sometimes there can be overlaps depending on what you're doing, but it's good practice to stick with the actual ASP.NET page life cycle and use the correct events. There is a good breakdown on MSDN of each event's actions.
Init for example is raised after the controls have been created, so any dynamic changes won't take effect immediately.
Related
I am new to WebForms, I think I have a rather simple question.
I often see people initialize any kind of dependencies in the page_load-method of their page class. Is that a common thing to do ?
Things I would usually write in the constructor.
How do I decide what belongs in the constructor and what is better placed in the page_load handling method
You must take a look at asp.net life cycle.
On costructor method you can write lot of code, declaring variables and using classes and libraries.
But if you need some asp.net elements (Page, Controls, Session, QueryString etc) you need to be in Page_Load or in other methods of life cycle.
When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend. Additionally, if you develop custom controls, you must be familiar with the page life cycle in order to correctly initialize controls, populate control properties with view-state data, and run any control behavior code. (The life cycle of a control is based on the page life cycle, but the page raises more events for a control than are available for an ASP.NET page alone.)
I am going through page life cycle.When i referring the following
there the LoadPostData() method is expressed as (First Try) later (Second Try).What does here try refer to?
I think you should refer to the original image from MSDN, it says that it called once for each control
The page calls this method once BEFORE the page Load event so that all controls on the page or created in the Init event will have their values set from the form post before you start working with them in the Load event code. It calls it a second time because you might have added some dynamic controls during the Load event, and this gives them a chance to get their values set as well.
This article is a good one that outlines the whole page lifecycle, step by step. You'll see a reference to this second try under the "Raised Events" section.
Question is pretty straight forward.
Is there a technical reason for the existence of Page.PreLoad or is this just convenience to have a place where you can neatly place code that always have to be executed before the Load code?
Is there a difference between adding code in the PreLoad event handler and adding code at the top of the Load event handler?
And what would be a typical scenario where you use PreLoad?
Thanks!
What happens between Page_PreLoad and Page_Load is that all the other PreLoad event handlers (not just the handler(s) you wrote) have a chance to run. There is no reason to put code in Page_PreLoad. You see, chances are that you do want to be sure all the other PreLoad event handlers have fired (I'll explain in the last paragraph). Plus, by using Page_Load instead of Page_PreLoad, you give control adapter authors a chance to override the behavior of your implementation.
The purpose of the Page.PreLoad event (as far as I can tell) is to provide a hook for control authors. The behavior of the load phase of the page lifecycle, is that the Load event is raised on the page before it is raised on all its child controls. As a control author, you might want to perform some action after viewstate is loaded (so Init is too early), but before Page_Load is called (so Load is too late). How you do that is to add an event handler to Page.PreLoad.
Some of the built-in ASP.NET data binding controls use this hook to be able to auto-magically re-DataBind themselves when you update the control in certain ways after its viewstate has been loaded. Using a flag set in Page.PreLoad, a control can distinguish between changes you make in Page_Init and changes you make in Page_Load. If you implement Page_PreLoad and you don't take care to avoid touching any control that hooks PreLoad in this way, you're going to see undefined behavior because you don't know whether PreLoad is firing on the control or on the page first. To avoid this complication, always use Page_Load instead, as there is no reason not to.
I'm sure I've answered this a few times, but you're best bet is to have a thorough read thorugh the ASP.NET Page Lifecycle Overview from Microsoft and the ASP.NET Page Lifecycle explanation from 15 Seconds.
There are plenty of articles that explain the ASP.NET WebForms page lifecycle, but what happens between the constructor in the code-behind page getting called and the Page_PreInit event? MSDN refers to this time as the "start stage" of the page.
I am debugging some code in which there is often a moderate delay between these two events (determined using logging, delay of the order of a few seconds).
There are several methods of the Page class that are called before the PreInit event is fired. Maybe one of those is responsible for the delay. See the following illustration, which is on the same page you included in your question: http://msdn.microsoft.com/en-us/library/ms178472.aspx#additional_page_life_cycle_considerations.
the first called function is Constructor.(obviously...)
after this other event will raised.
a) Am I right in assuming that only after controls on Master page are merged into the control tree for the Page, can controls ( both those in Master page and in a content Page ) be initialized with their declarative values ( values set during design time )?
b) If my above assumption is correct, then these controls cannot be initialized with their design-time values during Page.PreInit, since during Page.PreInit event stage we’re still able to dynamically set a Master page?! So if that is the case, when are controls initialized with their declarative values? During Init event or…?
thanx
Pages are compiled into .Net classes, so the parsing of the markup actually happens outside of the page lifecycle. By the time a request reaches your Page, the page class has been compiled from the combination of the markup and codebehind.
This is easily verified by just putting a Page_PreInit handler and looking at the properties of a control on the page. You'll see that they are set.
The MasterPage/Page relationship is just a function of how the HTML will get rendered, and the naming containers that everything lives in.
When the actual Page compilation happens is partially a function of how you've set up your project, and partially a function of ASP.Net's monitoring of the files in the application.