In the ASP.NET Page LifeCycle there is the Page.LoadComplete event.
The MSDN documentation says 'Use this event for tasks that require that all other controls on the page be loaded'. What exactly might this be? What would a 'best practice' say that LoadComplete should be used for?
When you hook up several methods to the Load event you don't know the order they will get called. So you have the PreLoad, Load and LoadComplete events to have some more control as to in what order your code gets called.
The use of this might not always be clear when working only with your page class. When working with controls however, with the need to have some code running at Load time, you might want to make it run right before or right after what would normally happen in the Load event. Then you can use the PreLoad and LoadComplete methods.
As simon mentioned, the same pattern is followed with the Init event...
More information can be found in this MSDN article about the ASP.NET Page Lifecycle
EDIT: It seems, from the MSDN article that LoadComplete is called AFTER your control events like Button.Click have been raised.
Say you have multiple controls that prepare some data in the load event. If you want to take action on that data in the load step of the ASP.NET lifecycle you need to have a way to execute after all the other load's have run. Hence the "load complete". There's also an "init complete".
Here is one example where I was trying to use Page_Load and someone correctly pointed out that LoadComplete would be better.
Related
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.
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.
Ok, I thought I understood these topics well, but I guess not, so hopefully someone here can clear this up.
Page.IsAsync seems to be broken. It always returns false.
But ScriptManager.IsInAsyncPostBack seems to work, sort of.
It returns true during the round trip for controls inside UpdatePanels. This is good; I can tell if it's a partial postback or a regular one.
ScriptManager.IsInAsyncPostBack returns false however for async Page Methods. Why is this? It's not a regular postback, I'm just calling a public static method on the page.
It causes a problem because I also realized that if you have a control with AutoPostBack = false, it won't trigger a postback on it's own, but if it has an event handler on the page, that event handler code WILL run on the next postback, regardless of how the postback occurred, IF the value has changed.
i.e. if I tweak a dropdown and then hit a button, that dropdown's handler code will fire. This is ok, except that it will also happen during Page Method calls, and I have no way to know the difference.
Any thoughts?
As Tjaart points out, Page.IsAsync has nothing to do with AJAX! See MSDN for a bit more info about IsAsync and see http://msdn.microsoft.com/en-us/magazine/cc163725.aspx for a fuller description of async pages].
Page methods are web services by a different name. The ScriptManager will emit the necessary JS boiler plate to make creating an XHR that invokes the web service very easy but that's all ScriptManager has to do with them really.
As the MSDN page states, ScriptManager.IsInAsyncPostBack will only be true if the request is in "partial rendering mode" so ScriptManager.IsInAsyncPostBack will be false when you are executing a page method because that request has not been spawned as a result of a partial postback (i.e. an UpdatePanel refreshing its contents).
Now it sounds like you are getting server side event handlers being executed as an apparent result of calling a page method from JS. AFAIAA, invoking a page method using javascript should not cause the page to go through its normal page lifecycle - so Page load, init etc. and these events should not be executing. So that is strange.
Suggestion: -
See Anz's comments and Dave's replies here encosia.
Could it be that you are having similar problems to Anz? i.e. The page method is invoked and but then your page is posting back immediatly after?
This is so because ASP.NET Ajax and ASP.NET Callbacks are two different things and are implemented differently. Unfortunately you have to use both Page.IsAsync and ScriptManager.IsInAsyncPostBack.
Page.IsASync probably returns whether the page was set as Async in the page directive
<%# Page Language="vb" Async="true" ...
The autopostback flag is so that you don't get a postback after every single control action, so the user can fill in an entire form and then only create the postback and trigger all the related code.
It's not really weirdness, they designed it this way so that the server side code will always be synchronized with the client side. So if you make a drop down list selection on the page and a postback occurs then that drop down list change executes it's own code along with the control that triggered the postback. You may want to read up more on the ASP .Net page lifecycle. it made things much more clear for me.
I am adding controls dynamically in my webpage.
I add them in onload method.
everything is working fine..
But I m a bit confused about how it works..
I have read in so many articles that all controls get their values from viewstate before load event. Then how my dynamically added controls get their values when i am adding them in OnLoad event ie after LoadPostData event.
Load them in Page_Init()
Review the page lifecycle for more info:
http://msdn.microsoft.com/en-us/library/ms178472.aspx
This is a helpful article as well:
http://www.code-magazine.com/article.aspx?quickid=0305101&page=2
In a typical GET request, the controls are created at Page_Init. Since these dynamic controls are not part of page markup, so in POST BACK, you need to recreate. Be sure that when recreating, it must have same ID otherwise your events/values will not preserve.
Dynamically added controls play catch up in the control lifecycle. Even if you add a control after it has missed the LoadViewState event, that event will still occur for the control at the time when the control is added to the page. I would suggest that any poor souls who have not had the privilege of reading this article, do so immediately:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
Source:
Professional programmer, I do not claim to be an expert, but I have read tons of articles about ViewState. :)