Miłosz Orzeł

.net, js, html, arduino, java... no rants or clickbaits.

View State for TextBox and other controls that implement IPostBackDataHandler

While reading the official training kit for 70-515 exam I came across this text: "With view state, data is stored within controls on a page. For example, if a user types an address into a TextBox and view state is enabled, the address will remain in the TextBox between requests.". If such statements can be found in recommended study guide, it should not come as a surprise, that confusion about the way ASP.NET Web Forms tries to cope with inherent statelessness of HTTP is so common… ;)

TextBox control from ASPX page:

<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>

is rendered on HTML page as an input tag:

<input name="TextBox1" type="text" id="TextBox1" />

If so, then the preservation of TextBox value between requests does not require any use of __VIEWSTATE hidden field. To illustrate this, create a simple page that contains TextBox and Button controls:

...
 
<body>
    <form id="form1" runat="server">
        <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
        <asp:Button ID="Button1" runat="server" Text="Button" onclick="Button1_Click" /
    </form>
</body>
</html>

and add a handler for button’s Click event, which only task is to extend the text in TextBox1 control:

protected void Button1_Click(object sender, EventArgs e)
{
    TextBox1.Text += "X";
}

Then, run the page and activate a tool for monitoring communication between browser and server. We are interested in testing form data that is sent to the server at postback... If you are using IE, I can recommend you a debugging proxy called Fiddler. Under Firefox, use Firebug. You can also use built-in ASP.NET Trace feature – to do so, add Trace = "true" to @Page directive. I performed my tests using development tools provided with Chrome browser ("Network" tab).

The following screenshot shows what form data (HTTP POST request) was sent after first button press:

Dane formularza przy pierwszym postbacku

And here is data from second postback:

Dane formularza przy drugim postbacku

If you compare data from first and second requests, you will see that a change in the value of TextBox1.Text does not affect the value of __VIEWSTATE field. Expanding the field would be a waste of network resources if text is being sent to server in a separate field called TextBox1.

System.Web.UI.WebControls.TextBox class is one of several classes that implement IPostBackDataHandler interface. This interface requires LoadPostData method. After page initialization is completed (but before the Load event) loading of View State data is invoked (LoadViewState) and then (if the control implements IPostBackDataHandler), loading of form data is invoked (LoadPostData). Text property of a TextBox control can therefore be set even if View State mechanism is disabled (via EnableViewState = "false" setting).

So... Can we completely disable View State mechanism for TextBox controls and the like?

No. For example, View State is useful when TextChanged event is handled (for comparison between current and previous value). It can also be used when the value that is being set is other than the one related to control’s value (e.g. ForeColor).