What is the difference between ViewState and ControlState in terms of IsPostBack and how they work?
What is the actual use of ControlState?
Control state is a new construct within ASP.NET 2.0, and it is really nothing more than view state; however, it is view state with a significant advantage; that advantage is that other developers using your control cannot disable control state as they can view state.
http://www.codeproject.com/Articles/15300/Using-Control-State-in-ASP-NET-2-0
The ViewState & ControlState both stores the control properties ,you can disable the ViewState Property only and that will not affect the ControlState at all which loads in the page first loading or if the page is postBack the controlState already loads from saved memory
Since Control State and View State are the same then first question is , isn't it duplication of data?
Then we realise there is an advantage to Control State that it cannot be disabled. Then we might think why can't we do the same to View State :) why invent a new "Control State" for that. Now we have duplication of data. The reason to disable View State is nullified by the presence of Control state, right?
That is where the real advantage of Control State comes in. Control State is versatile. That is, a custom control can decide what to store in a control state. Where as view state is not intended to be stored specifically by a control, it is a general out of the box feature available. Because control state has a specific reason(and it has to be dependable) it is not designed to be disabled.
Control state, introduced in ASP.NET version 2.0, is similar to view state but functionally independent of view state. A page developer can disable view state for the page or for an individual control for performance. However, control state cannot be disabled. Control state is designed for storing a control's essential data (such as a pager control's page number) that must be available on postback to enable the control to function even when view state has been disabled. By default, the ASP.NET page framework stores control state in the page in the same hidden element in which it stores view state. Even if view state is disabled, or when state is managed using Session, control state travels to the client and back to the server in the page. On postback, ASP.NET deserializes the contents of the hidden element and loads control state into each control that is registered for control state.
Related
Can i Consider the responsibility of InitComplete event as follows
1) It is the last stage of page initialization
2) If ViewState is enabled at page level it will calls Page.TrackViewState() method inorder to make the view state to be ready for persisted across postback.
Thanks
Babu
According to MSDN
Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event.
Use this event to make changes to view state that you want to make sure are persisted after the next postback.
1) It is the last stage of page initialization
Yep
2) If ViewState is enabled at page level it will calls Page.TrackViewState() method inorder to make the view state to be ready for persisted across postback.
Nope, by the time you get to InitComplete, ViewState tracking has already been turned on. As the last section of the documentation states, purpose of the even is to changes to the ViewState.
I have a ASP.NET 4.0 webforms site where I have the MasterPage so it is set to ViewStateMode="Disabled" along with the content placeholders being set similarly.
When I'd view my page I'd still see a ViewState field rendered, I then tried adding the ViewStateMode="Disabled" to the page level also but that didn't change anything.
I'm not aware of latest changes on ViewState for the framework 4 but you have to take into account that the ViewState field rendered to the client has 2 components: ViewState itself and ControlState.
The ControlState is ALWAYS sent to the client on the viewstate field no matter if you have enabled ViewState or not.
So you can expect to drastically reduce the size of the viewstate field sent to the client but not completely remove it.
Control state contains the minimal things that a control needs to persist across postbacks in order to work as expected.
Control State
In addition to view state, ASP.NET supports control state. The page uses control state to persist control information that must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control state is stored in one or more hidden fields.
http://msdn.microsoft.com/en-us/library/bb386448.aspx
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 have a simple user control containing two text boxes which I am adding to placeholder on Button Click event. I am storing the number(count) of clicks in View state and running a loop using count to create all previously added user control. I am also adding IDs to each User control (appending "UC" and count). I have also checked in view source the ids are same each time they are created. I have another button which basically does an post back. I have EnableViewState enabled ="true" in all controlls all the way up to Page Level.
My problem is that User Input does not persist on postback. please advice. Should this not be happening automatically for me?
Have a look at this:
http://www.denisbauer.com/ASPNETControls/DynamicControlsPlaceholder.aspx
I've encountered minor problems with it on a web farm, but for simple deployments its use is pretty straightforward. (Comes with source code, and the web farm glitch is a pretty simple fix.)
You need to create your dynamic controls in the Page_PreInit event rather than Page_Load or in a Click event handler. That way, they'll be there before ViewState, and then your posted values are applied.
I thinks what is happening is that you are creating your controls during the click event handler which happens AFTER ViewState and PostBack have been applied. This means your controls will be created empty each time.
I have an asp:Gridview bound to an asp:ObjectDataSource. I have disabled the ViewState on the GridView, and have not set the DataKeyNames property. I have about 10 BoundFields and a few TemplateFields. These TemplateFields are not bound to server controls but to an anchor tag or to an img tag.
However, at runtime, when I switch on page tracing I see that the ControlState of the Gridview varies between 7 and 12K for displaying just 14 rows of data. (View source on the rendered page also gives a same long string in the __VIEWSTATE hidden field). I do not understand why this happens as I have enableViewState="false" on the gridview and, as said above, I am not using DataKeyNames. So, where is this Gridview ControlState coming from and is there a way to get rid of it?
Thanks in advance,
Tim
i think its normal because:
control state cannot be disabled, Control state is designed for storing a control's essential data (such as a pager control's page number) that must be available on postback to enable the control to function even when view state has been disabled
note: By default, the ASP.NET page framework stores control state in the page in the same hidden element in which it stores view state. Even if view state is disabled microsoft said
that mean you actually saw the data of ControlState in _ViewState field which is ok
because as microsoft said the ControlState of the control stored in viewstate even if you disable ViewState
If you're disabling viewstate, not using any postback controls within the gridview, and not doing paging/sorting, then you're probably better off using a repeater. Repeaters don't have to be placed inside a tag. So, the control state won't be an issue.
If you're using .net 3.5 you could also investigate using the ListView, which to me seems like a repeater / gridview hybrid.
This article says that control state is actually stored in the __VIEWSTATE in a HybridDictionary.
Also, these articles say that even though you can set EnableViewState=false, you can never turn off ControlState (which is the point - so clients can't break your application):
Control State vs. View State Example
ASP.NET State Management Overview
ASP.NET State Management Recommendations