I have a textbox and button on my .aspx page. The EnableViewState property of the textbox is set to false. But when I enter some text in the textbox and click the button the
This is by design
The following server controls persist their information across requests even when the control ViewState (the EnableViewState attribute) is set to False:
* The TextBox control.
* The CheckBox control.
* The RadioButton control.
This behavior occurs because the ViewState of a control is only one of the methods that are used to persist a control's attributes across requests. In the server controls that are mentioned in the "Symptoms" section, attributes that are not normally posted to the server through the form-get or the form-post are handled by the ViewState. These values include attributes of the control, such as BackColor. Attributes that are normally posted to the server are handled by the IPostBackDataHandler interface. An example of such an attribute is the checked attribute of the CheckBox control.
Also read this article
ASP.NET: TextBox and EnableViewState="False"
For understanding of Viewstate I don't think there is a better article than MSDN
Understanding ASP.NET View State
Please check this Code Project article to better understand ViewState and Postback Data.
It is something like :
Why some controls retain values even after disabling the ViewState while others do not?
The answer is Controls which implements
IPostBackEventHandlerIPostBackDataHandler like Textbox, Checkbox, etc. will retain the state even after disabling the viewstate. The reason is during the Load Postback Data stage, these controls will get state information from Posted back form.But controls like label which do not implement
IPostBackEventHandlerIPostBackDataHandler will not get any state information from posted back data and hence depend entirely on viewstate to maintain the state.
Below is related paragraph to your question.
In page life cycle, two events are associated with ViewState:
Load View State: This stage follows the initialization stage of page lifecycle. During this stage, ViewState information saved in the previous postback is loaded into controls. As there is no need to check and load previous data, when the page is loaded for the first time this stage will not happen. On subsequent postback of the page as there may be previous data for the controls, the page will go through this stage.
Save View State: This stage precedes the render stage of the page. During this stage, current state (value) of controls is serialized into 64 bit encoded string and persisted in the hidden control (__ViewState) in the page.
Load Postback Data stage: Though this stage has nothing to do with ViewState, it causes most of the misconception among developers. This stage only happens when the page has been posted back. ASP.NET controls which implement
IPostBackEventHandlerIPostBackDataHandler will update its value (state) from the appropriate postback data. The important things to note about this stage are as follows:
- State (value) of controls are NOT retrieved from ViewState but from posted back form.
- Page class will hand over the posted back data to only those controls which implement
IPostBackEventHandlerIPostBackDataHandler.- This stage follows the Load View State stage, in other words state of controls set during the Load View State stage will be overwritten in this stage.
Take a look at Server controls persist their state when EnableViewState is set to False
The following server controls persist their information across requests even when the control ViewState (the EnableViewState attribute) is set to False:
This behavior occurs because the ViewState of a control is only one of the methods that are used to persist a control's attributes across requests. In the server controls that are mentioned, attributes that are not normally posted to the server through the form-get or the form-post are handled by the ViewState. These values include attributes of the control, such as BackColor.
Attributes that are normally posted to the server are handled by the IPostBackDataHandler interface. An example of such an attribute is the checked attribute of the CheckBox control.
Example: Consider backcolor setting programmatically. On postback, if viewstate is switched off, the background color
of the Textbox control is lost. However, the text value of the control is maintained.
Note: If the backcolor was set directly in markup rather than in code behind, it would have persisted.
<form id="form1" runat="server">
<asp:TextBox ID="Textbox1" runat="server" EnableViewState="false"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" EnableViewState="false" />
</form>
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
this.Textbox1.BackColor = Color.Yellow;
}
}
Following is from Understanding ASP.NET View State:
It is a common misconception among developers that view state is somehow responsible for having TextBoxes, CheckBoxes, DropDownLists, and other Web controls remember their values across postback. This is not the case, as the values are identified via posted back form field values, and assigned in the LoadPostData() method for those controls that implement IPostBackDataHandler.
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 theposted 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.
Also refer following
View State for TextBox and other controls that implement IPostBackDataHandler
How do I disable viewstate for a specific control?