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
Related
I've been working with C# and .NET for quite some time now, but am currently working on my first ever web application with ASP.NET. It took me quite some time playing around to realize that the Page_Load function was getting called before my button event handler, though, at this point I've got the application working properly around this behavior. However, the issue I'm having is this:
I have a GridView control that is bound to a SortedList in my application. The button click event handler saves data in a form to the database (actually, saves data via a SOAP service), then updates the list that the GridView is bound to in order to reflect the most up-to-date data (again, updates the list from the SOAP service). However, because the page refreshes before my button click event handler fires, the data doesn't actually appear updated on the page. What is the proper way to handle a situation like this? How can I get the data on the page to be refreshed, or at least up-to-date, after the button handler saves data even though the page has already refreshed? I've been struggling with this for quite awhile now, so any code example or links that'll help explain this would be much appreciated.
Thanks in advance!
try inside Page_Load
if (!IsPostBack)
{
//Bind your Grid
}
just write your code in below if condition.
if(!IsPostBack)
{
write your code here in formload.
}
I want to correct Harag's link to the resource regarding the page lifecycle. It can be found here: http://msdn.microsoft.com/en-us/library/ms178472(v=vs.100).aspx.
Though not an answer to the OP's question, I restate it because it's such an important concept to know once you start programming web forms on a more serious basis.
I'm using a file manager-type WebControl that does lots of postbacks. It's placed inside a Page that is relatively complex. I would like to prevent the WebControl from causing the whole Page to go through the lifecycle. An UpdatePanel helps a little, but not enough.
Is there any way to isolate the WebControl from the rest of the Page? The only way I can think of is sticking the WebControl in a separate Page and creating an iframe in the original Page. Unfortunately that also means my WebControl properties/settings are no longer in the original Page. If I want two instances of the WebControl with different settings, then I have to create a Page for each setting and reference the correct one in my iframes. Not quite as "drag & drop" as I would like. Any other suggestions?
Hard to tell, you can't prevent a control from going through lifecycle; is there anyway to identify though, that during a certain page postback, you prevent the code from running in each event handler by doing something like:
if (_shouldNotRun == true)
return;
//Event handler code
Essentially, figuring out some way to indicate whether the control should run may be an option. IFrame would work, but yes you have to deal with the issues you mentioned. Can you give more detals to the problem?
HTH.
Not 100% sure what events possible to override that are called on PostBack. A good source for the Life Cycle of a page (http://msdn.microsoft.com/en-us/library/ms178472.aspx)
But it sounds as it would be better to remake your control to create Ajax webservice requests for the functions that are possible to prevent most of the postback's?
Cheers,
Stefan
I have an ASP.NET user control that I'm embedding in another user control. This works fine.
I need to know the best logic/method for detecting when the control is loaded. In other words, I have some display initialization logic that needs to run when the control is initially displayed. Surely there is a pattern for this.
The typical method is to put (!IsPostBack) logic in the Page_Load method of the control. This works great until you end up with a state when the Parent page has already posted back many times. My user control gets added to the page but its display does not intialize properly.
I'm hoping to find a way that keeps this logic inside the control, versus various hacking around in the codebehind of the parent page.
See the following MS article. They have an example that places several controls within a user control and initializes them.
There is another post here on StackOverflow that seems similar. You may want to check it out, and see if it points you in the right direction.
It may also be helpful to review the page life-cycle and events.
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
I have a problem with maintaining state in an ASP.NET AJAX page. Short version: I need some way to update the page ViewState after an async callback has been made, to reflect any state changes the server made during the async call.
This seems to be a common problem, but I will describe my scenario to help explain:
I have a grid-like control which has some JavaScript enhancements - namely, the ability to drag and drop columns and rows. When a column or row is dropped into a new position, an AJAX method is invoked to notify the control server-side and fire a corresponding server-side event ("OnColumnMoved" or "OnRowMoved").
ASP.NET AJAX calls, by default, send the entire page as the request. That way the page goes through a complete lifecycle, viewstate is persisted and the state of the control is restored before the RaiseCallbackEvent method is invoked.
However, since the AJAX call does not update the page, the ViewState reflects the original state of the control, even after the column or row has been moved. So the second time a client-side action occurs, the AJAX request goes to the server and the page & control are built back up again to reflect the first state of the control, not the state after the first column or row was moved.
This problem extends to many implications. For example if we have a client-side/AJAX action to add a new item to the grid, and then a row is dragged, the grid is built server-side with one less item than on the client-side.
And finally & most seriously for my specific example, the actual data source object we are acting upon is stored in the page ViewState. That was a design decision to allow keeping a stateful copy of the manipulated data which can either be committed to DB after many manipulations or discarded if the user backs out. That is very difficult to change.
So, again, I need a way for the page ViewState to be updated on callback after the AJAX method is fired.
If you're already shuffling the ViewState around anyway, you might as well use an UpdatePanel. Its partial postbacks will update the page's ViewState automatically.
Check out this blog post: Tweaking the ICallbackEventHandler and Viewstate. The author seems to be addressing the very situation that you are experiencing:
So when using ICallbackEventHandler you have two obstacles to overcome to have updated state management for callbacks. First is the problem of the read-only viewstate. The other is actually registering the changes the user has made to the page before triggering the callback.
See the blog post for his suggestions on how to solve this. Also check out this forum post which discusses the same problem as well.
I actually found both of those links you provided, but as noted they are simply describing the problem, not solving it. The author of the blog post suggests a workaround by using a different ViewState provider, but unfortunately that isn't a possibility in this case...I really need to leave the particulars of the ViewState alone and just hook on to what is being done out-of-the-box.
I found a fairly elegant solution with Telerik's RadAjaxManager. It works quite nicely. Essentially you register each control which might invoke a postback, and then register each control which should be re-drawn after that postback is performed asynchronously. The RadAjaxManager will update the DOM after the async postback and rewrite the ViewState and all affected controls. After taking a peek in Reflector, it looks a little kludgy under the hood, but it suits my purposes.
I don't understand why you would use a custom control for that, when the built-in ASP.NET AJAX UpdatePanel does the same thing.
It just adds more complexity, gives you less support, and makes it more difficult for others to work on your app.