I do have a small doubt regarding ASP.NET Page Life Cycle events. When gone through the coding of an application I came to see both overriding of OnInit() method and also Page_Init event. I thought both the approaches serves the same purpose and i saw mostly the implementation of overridden OnInt() only but not both. Most of the articles in the web explains about the better approach in these two and I know that generally overriding the OnLoad/OnInit methods is faster and also if you override OnInit and fail to call base.OnInit then the Init event won't be fired but no one explained what happens if we implement both. What does this situation means. Can anyone please help me regarding this. Thanks in Advance.
Page_Init is just a shortcut for calling the OnInit override they both do the same thing. Page_Init requires the AutoEventWireup property to be set to true because it tells the compiler to look at your code for certain methods like Page_Init or Page_Load and fire them, this video from Fritz Onion on pluralsight does a really good job of explaining it: ASP.Net 3.5 Pluralsight Course
Related
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.
I have a page and few controls. I'm doing a normal postback.
On InitializeCulture event of the page the Page.Request object contains e.g. controls with their values - and that's great.
But on the other hand, when I'm trying to access this collection on the Page_Load or OnInit events, it's way smaller and doesn't have any of the controls that have been there before.
Can anyone tell me what happens with Page.Request between these events?
EDIT:
Thanks guys, I was aware of the Page Life cycle term:) and these links were indeed helpful.
I probably haven't pointed that out clearly , but:
inside override method for InitializeCulture() I Page.Request is full of various controls. Right after calling the base.InitializeCulture() , Page.Request has only server variables. I could look for values of my controls here, but can't do it - the controls are not initialized yet (so calling Request.Params.Get(SomeControl1.UniqueID) throws error)
overriding PreInit, Init or Page_Load doesn't help at all.
So the question is what and when happens with Page.Request between InitializeCulture() and next events that makes it smaller?
Btw. I find http://i.msdn.microsoft.com/dynimg/IC386473.png a much better illustration of Page Life Cycle.
EDIT:
What a mistake. Someone was doing a redirect which was resetting the whole Request collection... Lame of me. I would delete this post, but cannot.
Basic page life cycle will answer your question
Full article: http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx
Image Source: ASP.NET application and page life cycle, by Shivprasad Koirala, 19 April 2010
I have a usercontrol used in a masterpage.
I have added a page with the masterpage.
Now I need to call a method of the user control from the page.
How to do this? Please help.
Assuming that your method is public and your user control's type is YourUserControlsType, try this :
YourUserControlsType ctrlAtMasterPage =
(YourUserControlsType)Page.Master.FindControl("YouControlsID");
ctrlAtMasterPage.YourPublicMethod();
This should get you your control even if it was added programatically:
In a member of the page you added:
TextBox FoundTextBox = (TextBox)this.Master.FindControl("RunAtServerTextBoxServerID");
If you don't have a member reference to the control you should consider decoupling the page from the control. In an ideal world, the page should not necessarily know about a control it may or may not contain. Therefore, you might look into an implementation of the MVP pattern.
There's a simple implementation of MVP here, and you can see the decoupling in action here. If you reverse the communication from the decoupling example (i.e. page fires an event that the control picks up), then basically, you've decoupled your page from the control. This has a benefit in that if your page changes and the control is no longer in use, the event is not picked up by anything and your page continues to execute with no problems. I find this much more suitable than a potential null reference exception when FindControl doesn't find the control and then you try to execute a method on it.
While decoupling may take a few extra minutes, in many scenarios it turns out to be a worthwhile endeavor.
I've been digging thru the Page, TemplateControl and Control classes in reflector trying to figure out where AutoEventWireUp property is actually getting used. I've failed miserably.
My understanding of AutoEventWireUp is sketchy but I think it casues event handler methods to be automatically wired up to events?
So I thought I'd see some code where this is happening, but this isn't the case.
Where is AutoEventWireUp actually used under the hood? Can I see the code in reflector?
Thanks in advance!
I was going to write up an explanation but K. Scott Allen has a much better one.
My advice is to avoid AutoEventWireup and either override base "OnEvent" methods or explicitly wire up your own events as this will be faster, less magical, and easier to debug.
I know it happens sometime before Load, but during what event exactly?
It's loaded into memory between init and load. See this article for a full break down of the page lifecycle.
I once got into this question too and got my answer from TRULY understanding Viewstate article, which I highly recommend.
After reading it I designed a graphic that helped me to understand better what was happening on between each stage and when and how ViewState was doing its job.
I'd like to share this graphic with other people that (like myself) need to see how stuff work in a more visual way. Hope it helps! :)
Click on the image to view at full width.
That is to say, viewstate is loaded between the OnInit() and OnLoad() events of the page.
My favorite article on dealing with viewstate, which answers every question I have every time: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
You can see from the page life cycle as explained on MSDN
That the view state is loaded during the Load phase of the page lifecycle, i.e. the LoadViewState method of the "Page methods" and the LoadViewState method of the Control methods, above.
The Viewstate is actually loaded in the OnPreLoad event of the page,Just after the Page_InitComplete.
The viewstate is actually loaded between initComplete and Preload events.Check this for details http://msdn.microsoft.com/en-us/library/ms178472.aspx