Common misconception that ViewState holds values for controls such as TextBoxes.
Most ASP.NET developers think that the ASP.NET ViewState is responsible for holding the values of controls such as
TextBox so that they are retained even after postback. But this is not the case.
Let’s understand with an example.
Place a web server
TextBox control, an HTML server text box control (normal HTML input box with
runat=server), a normal HTML input control(without runat=server), and a web server
Value property to “Initial Text” for the three
TextBoxes, and set the
Text property of the
Label control to “Initial Label”.
EnableViewState property to false for the first text box and the last controls (Label).
Now 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
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) was 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. So the ViewState is responsible for persisting its value across postbacks, and since it has been disabled, the
Label 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.
So we conclude that controls which inherit from the
IPostBackDataHandler interface will retain their values even if the ViewState has been disabled, as their values are stored in HTTP POST headers.
Click here to view the original version by Vivek Thakur.