I have a page and a user control inside it.
I assign a value to viewstate in the control and do
Server.Transfer(Request.Url.AbsolutePath);
but when I check the value on control's Page_Load() event the assigned value doesn't exists (viewstate is empty, has not keys).
Why might this happened?
ViewState is stored on per-page basis. As soon as you do a Server.Transfer you're going to lose the ViewState from the page you're transferring from, which seems to be where your control is located? ViewState is only persisted during postback.
Number two, you might be explicitly turning off the ViewState for a page or a single control and not realizing it.
Related
I am very new to Asp.Net.
Almost all the controls i have seen till now has ViewState.
So, my question is Are there any controls that don't have ViewState ? What are they.
I have googled, but din't find the correct solution.
Thank you !!
Every control has ViewState because that is where all attribute values are stored.
To avoid ViewState you can disable it on the control (EnableViewState=false) and make sure when you set any properties (like Text, Visible etc.) you do that yourself on every postback (so that ViewState is not needed) - so in events like Page_Load instead of Button_Click.
I'm reading up to get a better idea of how viewstate works in asp.net webforms and have been reading this article.
One part that I don't quite understand is the Stage 5 - Raise postback event, it says that this stage does not make use of any viewstate information to raise the events (ie. TextChanged).
I thought that the viewstate would be sent back with the page on the postback and after the control tree had been populated the values from the viewstate would then be loaded in and then after that the control would interrogate the new form values comparing them against the current ones loaded from viewstate in order to tell which Changed() events it needs to raise.
If this event doesn't interact with viewstate how can it tell whether a value has changed or if it is still the same from the previous load?
Daniel, you are correct in your assumption - view state is used to determine whether a change-related event needs to be raised. That includes things like the TextChanged event on the TextBox and the SelectedIndexChanged event on the DropDownList, among others.
If you haven't read this article yet, I highly recommend it: Truly Understanding View State. It's an informative write up by Dave Reed.
Thanks!
In the case of TextChanged events, it does look at the viewstate to determine if it gets raised or not - see the answer to question 6215046:
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.textbox.ontextchanged.aspx
A TextBox control must persist some values between posts to the server for this event >> to work correctly. Be sure that view state is enabled for this control.
Try enabling ViewState for TextBox.
I have searched the web for the answer and saw that mostly variables are saved in viewstate on page.prerender event. Then the value of the variable is set back in page load event.
However, when I save a variable in viewstate on prerender or load events, how can viewstate store the value of the variable after it is changed dynamically on codebehind?
Let's say, after page is loaded, user clicked a button which changes the value of the variable in its onClick event. Then the postback event raised since the button was clicked. According to me, the new value should have been lost and cannot be saved in the viewstate if the variable is saved in the viewstate only in prerender event. Because on postback the prerender event wont fire and the value cannot be saved.
Shouldn't I save the variable in the viewstate just before the postback event rises?
Am I wrong? If so, how can viewstate store the new value of the variable if the viewstate is saved in prerender event?
Thanks for the answer in advance..
I suspect you're confusing saving ViewState, ie. serializing the ViewState collection in memory to a string representation or to an intermediate object that can be serialized easily, with actually modifying that ViewState in-memory object with its regular accessor methods.
What you may be hearing is that the SaveViewState() method is called after PreRender event. But that has little to do with when you get to modify the contents of the ViewState collection.
Checkout points 7. Prerender the Objects and 8. ViewState Saved in the article The ASP.NET Page Life Cycle. There's a good MSDN article that touches on this as well.
(source: microsoft.com)
As per ASP.Net Page Lifecycle Overview (emphasis is mine)
PreLoad()
Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request() instance.
....
SaveStateComplete()
Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.
As both Control Events and the PreRender event occur between these two, then your data should be persisted in ViewState.
Viewstate is maintained via a hidden field, so Postback has to finish before it's "set".
If you're setting it and trying to read it in the same page cycle it not going to work. You might try using the Session object, which get/sets values into memory.
I sort of answered my own question I think but I want to make sure I am understanding correctly. I initially thought that when a user provided values in a form, that on postback the values were submitted as part of the Viewstate, because TextBox.Text is part of the viewstate. Now I have found that user supplied values actually aren't applied to the controls until after the OnLoad event. This confused me because I thought that viewstate was loaded into the controls before OnLoad(or when calling Controls.Add()). I have gone over the documentation on page and control lifecycles a few times and I am just now realizing that there was a different step for handling postback data(this step didn't appear in a lot of documentation :(
1) So postback data, the values user's type into the fields, is applied after the OnLoad event, and Viewstate data is applied just before the OnLoad event?
2) So essentially all this means is that on postback the server gets two values for a TextBox.Text property, the one in Viewstate, which is like the "old" value from the previous request, and the new value supplied by the user in the form?
3) Does the .net framework apply postback data the same was as Viewstate, in that it finds the appropriate control via it's ID property? This is important because I am creating controls dynamically and I may even have forms that change structure overtime and need to think about how I handle ID's. So far I haven't been setting the ID property and everything works fine but things may be more complicated later on.
4) Does viewstate data ever get modified at all on client side? Or is the viewstate identical to what was sent by the server in the previous request(assuming no tampering)? My impression used to be that the server encoded all the control properties into the viewstate, and on the client side when the user submitted the form, the viewstate field was decoded, modified, encoded, and submitted to the server with modifications. I assumed there was a bunch of javascript doing all this for me. Now I think I had it all wrong. Instead it seems that the Viewstate never changes on client side, and all the client changes are in the postback data such that the next request the server loads viewstate, loads postback, and provides a new updated viewstate in the next response?
1) Both are loaded before Load
2) Basically, yes
3) ViewState is applied first, then Post Data
To quote Scott Mitchell(see below)
dynamically added controls must be
programmatically added to the Web page
on each and every page visit. The best
time to add these controls is during
the initialization stage of the page
life cycle, which occurs before the
load view state stage. That is, we
want to have the control hierarchy
complete before the load view state
stage arrives. For this reason, it is
best to create an event handler for
the Page class's Init event in your
code-behind class, and add your
dynamic controls there.
4) Unless you're doing something way outside of the box, ViewState is never modified client-side. "ViewState" is an HTML form field and is processed on the server side.
Here's a few images from Understanding ASP.NET View State by Scott Mitchell that may help you.
(source: microsoft.com)
(source: microsoft.com)
Bonus Reading Material: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
My impression used to be that the server encoded all the control
properties into the viewstate, and on the client side when the user
submitted the form, the viewstate field was decoded, modified,
encoded, and submitted to the server with modifications.
No, the point of the ViewState is simply to preserve the state of the page since the last "Save View State" page event, i.e. that event occurs shortly before the page is rendered to the client.
When the client makes selections to a dropdown box or changes text in a textbox the hidden ViewState property, which exists on the client page as a static HTML tag, is not dynamically changing / encoding those values, it remains the same as when the page was originally rendered.
So how is the new state of the page being preserved, i.e. how are user dropdown selections and text box values retained in ASP controls? Those dropdown selections and text box values are captured in Post Back data.
A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface. In this stage in the page life cycle, the Page class enumerates the posted back form fields, and searches for the corresponding server control. If it finds the control, it checks to see if the control implements the IPostBackDataHandler interface. If it does, it hands off the appropriate postback data to the server control by calling the control's LoadPostData() method. The server control would then update its state based on this postback data.
- Scott Mitchell
I am having a listbox in ASP.net. I am populating the listbox values from another listbox in a page dynamically. During postbacks the values of output listbox are not persisted.
(while going to another page and come back to this page).
Please suggest some good answer. EnableViewstate = "true" is not working.
Are you doing anything in Page_Load that should be in a
if(!IsPostBack) {}
Initialization code in load needs to only be called when the page is first loaded, not on postbacks.
If you are going to another page and then coming back to this page, I think you need to preserve the information yourself in the Session and then restore it when you come back to the page.
The viewstate is only preserved as long as your on the same page doing postbacks.
As Lou Franco wrote
if(!IsPostBack) {}
You use this on the initial pagerequest to fill in the data. if you wish to preserve the data across pages using the session to store the values is the best bet.
preferably you fill in the data in your listbox before the SaveViewState event thats in PreInit as far as I recall.
Initialize the content of your controls in your Page's Init event (Page_Init). That way any values the user supplies are not overwritten by your defaults.
EnableViewState will just repopulate the output listbox with the values that it had when the page first rendered, since they're still the ones stored in the viewstate. The browser sends only the selected value in the postback, so there's no way for the server to know what other values you added on the client.
You can work around this by adding a hidden input to the page and populating it with the dynamic values when you update the listbox. Your page can then check that value during a postback and repopulate the list properly.
Changes made to the listbox on the client side are not persisted during a postback, you need to record that information in hidden fields and then configure the control during the page_load event to make the changes stick during the rest of the postback.