ASP.NET Viewstate and ControlState

Difference between ViewState and ControlState

ViewState is the technique by which an ASP.NET Web page can save changes to the state of a Web Form across postbacks, without using Session or any other server variable. The ASP.NET runtime stores viewstate inside a hidden element in the redendered page's HTML, using BASE64 encoding. You can encrypt the viewstate too by simply modifying basic settings in the web.config file. Control state, introduced in ASP.NET version 2.0, is similar to view state but functionally independent of view state. We can disable viewstate for a page or for an individual control for performance but control state cannot be disabled. Control state is used for storing a control's essential data  that is needed on postback to enable the control to function even when view state has been disabled. Control state is stored in the same hidden element in which view state is stored. 

Most ASP.NET developers think that the ASP.NET ViewState is responsible for holding the values of controls such as TextBoxes so that they are retained even after postback. But this is not the case.

I'll explain this with an example. Let's understand this with a simple ASP.NET web project in C#, VS 2005/2008.

Open a new ASP.NET Web Application, and on the WebForm, place the following controls accordingly:

Place a web server TextBox control, an HTML server text box control (normal HTML input box with runat=server), a normal HTML input control, and a web server Label control. Name the four controls as:

• txtWebServerTest
• txtHtmlServerTest
• txtHtmlTest
• lblTest

Set the Text/Value property to “Initial Text” for the above three TextBoxes, and set the Text property of the Label control to “Initial Label Value”.

Set the EnableViewState property to false for the first and the last controls.

Beneath these controls, place two Button controls and set their text as “Change Label’s Text” and “Postback to Server”. On the button click event handler of the first button, write the following code:

private void btnChangeLabel_Click(object sender, System.EventArgs e)
{
    lblTest.Text = "Label's Text Changed";
}

There is no code on the second button’s Click event. It just submits the page to the server.

Now run this application. You can see the initial texts in the controls as you have set.

Now, change the text in all TextBoxes and set them to “Changed Text”. Now click the Post to Server button. What happens is that the first two textboxes retain their values, in spite of the ViewState property being set to false. But the last textbox, which is a simple HTML input control, loses the modified value when the page is reloaded.

Most developers would have expected all three textbox controls to lose their modified values (“Changed Text”), and after page re-loading, they expect “Initial Value” being written on all textboxes as we had disabled the ViewState.

The reason for this behavior is that ViewState is not responsible for storing the modified values for controls such as TextBoxes, dropdowns, CheckBoxList etc., i.e., those controls which inherit from the IPostBackDataHandler interface. After Page_Init(), there is an event known as LoadViewState, in which the Page class loads values from the hidden __VIEWSTATE from the field for those controls (e.g., Label) whose ViewState is enabled. Then the LoadPostBackData event fires, in which the Page class loads the values of those controls which inherit from the IPostBackDataHandler interface, (e.g., TextBox) from the HTTP POST headers.

Now, start the application again, and this time, click the “Change Label’s Text” button. When the page reloads, you will see that the programmatic change (made by our code in the event handler of the button’s Click event) is visible. But if not you click Post to Server button (or any other button which simply submits the form and reloads the page), the changed text of the lable is lost i.e., we don’t see the Label’s text changed to “Label's Text Changed”. Instead, we see the initial value of the Label again. This is because the Label control does not inherit from the IPostBackDataHandler interface, and hence will not get loaded from forms POST data. So the ViewState is responsible for persisting its value across postbacks, and since it has been disabled, the Labele loses its value after clicking the “Change Label’s Text” button.

Now enable the ViewState for the Label control, and you can see the modified value (“Label's Text Changed”) after clicking the same button.

While it is true that the ViewState does not contain any user changed values for a control which is being posted back the ViewState does contain the value(s) which have been added to the control in code (likedropdownlist) or the value from the previous postback (in the case of a text box).

Consider a dropdown list added to the page with 3 items added in the ASPX page. In the Page_Load 2 more items are added to the dropdown

Page_Load 
{
  if (!IsPostBack)
  { 
    DropDownList1.Items.Add("D");
    DropDownList1.Items.Add("E");
  }
}

These items will never be added except on the first load of the page, if you set EnableViewState=false when the page loads you will have 5 items. If the page posts back then when it re-renders there will be only the 3 items which are added from the ASPX.

A Text control works the same way except that the result isn't as noticeable it's not often that you want to work with the previous post back value but it does come up, expecially when dealing with dynamic controls based on user input. So while disbaling viewstate for controls such as textboxes, we have to be careful because sometimes we do need viewstate enabled to retain properties such as readonly for a textbox!