It will be long and detailed.
Start with this markup. Almost identical to yours, with one extra button and shortcut. I will explain why we need them later.
<form id="form1" runat="server"> <div> <asp:Label ID="Label1" runat="server" EnableViewState="False" ViewStateMode="Disabled" Text="Before click"></asp:Label> <asp:TextBox ID="TextBox1" runat="server" EnableViewState="False"></asp:TextBox> <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_OnClick"/> <asp:Label ID="Label2" runat="server" Text="Blah" /> <asp:Button ID="Button2" runat="server" Text="Button" OnClick="Button2_OnClick"/> </div> </form>
And we will use this code. Again, I will explain the purpose of the second handler later:
protected void Button1_OnClick(object sender, EventArgs e) { Label1.Text = "Changed"; } protected void Button2_OnClick(object sender, EventArgs e) { Label2.Text = Label1.Text; }
Let's see what happens when we first load the page. First, ASP.NET reads all the markup, and then goes through the life cycle of the page with all the events. At the parsing stage of the markup, Label1 receives the assigned text Before click , and it never changes later during boot. Thus, a later phase of rendering is what is rendered in HTML and sent to the browser. Thus, Before click displayed on the screen. Nice and easy.
Now we press Button1 . A postback occurs, which is a term that describes a request sent to the same page by one of its controls after it was originally loaded. Again, it all starts with an analysis of ASP.NET markup, and again Label1 gets the assigned text Before click . But then page life cycle events occur that entail control event handlers. And in the handler for Button1 text Label1 changed to Changed . Now here is what is important to note. If ViewState for Label1 was enabled, this new value will be stored there, and so-called tracking will be enabled for the Label1.Text property. But ViewState is disabled, so the new value is not stored anywhere except Label1 . The next step is the rendering page stage, and since Label1.Text still contains the Changed value, this is what is rendered in HTML and sent to the browser for display. However, note that this new value is not sent inside the ViewState field. As you can see, whether ViewState is turned on or does not play any role in what is displayed after this postback.
Now we press Button2 , which will cause another postback. Again, ASP.NET parses the markup, again Label1 gets the text Before click . Then, the ViewState download part is loaded. If ViewState for Label1.Text been enabled, it will load the changed value into this property. But ViewState is disabled, so the value remains unchanged. Thus, when we reach Button2 the click handler, the value of Label1.Text remains Before click , to which Label2.Text assigned. But Label2 has ViewState enabled, and therefore this new value for its text is stored in ViewState and sent to the client (ViewState is implemented as a hidden field on the client side). When everything gets to the browser, we can see Label1 and Label2 both Before click displays.
And to nail it, we will do the third rollback, now again pressing Button1 . Just like during the first postback, Label1 ends with the text Changed . But what about Label2 ? Well, this one has a ViewState enabled, so during the initial parsing of the markup, ASP.NET assigns it a Blah value, and at the time of loading ViewState it replaces this value with Before click . Nothing else affects this value during the life cycle of the page (we did not press the Button2 button this time), and therefore we finally see Changed and Before click in the browser.
I hope this makes it clear what ViewState is for and what it disables. If you want to delve deeper into the work of ViewState, I would highly recommend this article: TRULY Understanding ViewState