I have read this page: Viewstate n page lifecycle and also ASP.NET page lifecycle . My questions are these:
1 - Instantiaton means that the code for the control hierarchy is CREATED, and then in Initialization stage, it's executed, right?
2 - Does the Instantiation stage which is described in the page lifecycle, occur everytime? That is, does this occur for the first time and also during postbacks??
Yes, the control hierarchy is rebuilt every single time the page loads (including postbacks).
On Postback, The controls are hydrated with values from the ViewState.
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 working on a project which creates controls dynamically for a form in the page_load event, loads in their current values from the database and saves their values (using FindControl) when the user clicks the continue button.
When I added a control statically in the .aspx page and followed their same procedure of loading the value in the page load and saving it on the button press I found that the value would not save correctly. It seems that it wouldn't save because the click event fires after the page_load, so the page_load of the post back reverted the value and the user entered value was not saved.
The strange thing is that by changing the control to be dynamically created just as all the other controls on the page and keeping the loading and saving the same it now works. Even though the page load still creates the control with the old database value.
It seems like a very fundamental asp .net feature here but i'm just unclear as to what is going on. I suspect it is to do with the timing of creation and maybe when the view state kicks in.
Static page controls are created just like dynamic page controls. The difference might be coming in your Page_Load. Whenever you postback all the controls are created afresh which means they are created with their initial values. This happens because after creating the controls asp.net throws away the controls/objects.
So, when the request comes, the first thing that asp.net does it to recreate the controls by looking at their definitions (in the designer files). On each postback they are created and initialized again losing their state in the process.
But after creating the controls Asp.Net loads any viewstate that is sent along with the request which makes people think that the state is always saved at the server.
What might be happening is that either the viewstate is not enabled for your control (in case they are created in designer), in which case you may try using EnableViewState property to true of the control.
Or, when you're doing a Page_Load, you're forcefully re-initializing everything. And in process losing all the control data. If you could post the logic of Page_Load, it might get clarified.
Make sure that:
you are not setting the value again for the static control in Page_Load. The dynamic control are probably getting around it by grabbing the ViewState and form values at a different stage in the lifecycle.
The dynamic controls are added After the static control. Or at least they are added in a different container. Placement in the control's collection can affect the ViewState, although it doesn't look like your scenario / since what you mention seems to be more about the values in the current post.
The save is happening After the Page_Load in response to the corresponding event.
I've run into similar problems in the past (quite a few times actually), but what helped me the most is understanding the ASP.NET Page Lifecycle.
Microsoft has an article on it which describes it pretty well, but this post by Solomon Shaffer really cleared up everything.
I suggest reading them both and coming back with additional questions regarding to a particular state, when to load/save data etc..
Hope this helps.
Marko
Note that you may want to use Page.IsPostBack property to avoid reinitializing values on button clicks and other events.
private void Page_Load()
{
if (!this.IsPostBack)
{
// Assign values to the controls.
}
}
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.
I have 2 aspx pages. Both of them use the same MasterPage and both of them inherit from the same base class 'BasePage' which is of type System.Web.UI.Page. I overrode the SqlPagePersister property on the BasePage. For 1 page this works fine, for the other it doesn't. The sequence of events im seeing is this:
Page A:
MasterPage Init
Page Load
Retrieval of SqlPagePersister Property
Page B:
Retrieval of SqlPagePersister Property
MasterPage Init
Page Load
Why would 2 pages with an identical set up call these methods out of order and what can be done to fix this?
The sequence of events for Page B can't happen in the life cycle of an ASP.Net page. The master page init and page load must be in a state of being "re-fired". You may want to look at any previous page action that is being shunted into Page B because the init/load must happen before the retrieval can even begin.
There must be some action happening before Page B property retrieval, but that doesn't mean you're going to catch it necessarily in your debug with your normal casual breakpoints. You may have to get creative and start at the PreInit of your base class.
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.