This article aims at understanding why and when we need to have
ControlState for the state management. We also try to understand the same with a very basic implementation of control state.
By default, the ASP.NET page has
true. This makes ASP.NET automatically keep track of state of all the controls present on the page. Now if I am working on a web page where I know all the controls will be dynamically bound to some data on each postback, I don't have to keep track of the old information for the controls. So I might decide to turn it off. Now this is a perfectly good choice for the page developer but things could get messy if the same page contains a custom control and that custom control is using
ViewState to manage the data inside the control.
The main focus here is to look at from a Control Developers point of view. How can I write controls that are immune to the controls users' action, i.e., it will work in any case whether
ViewState is ASP.NET enabled or disabled.
Using the Code
ASP.NET already provides a mechanism for such scenarios and it's called
ControlState. Here we will simply try to see the right way of writing a custom control with proper
Suppose we have a very simple custom control that displays a couple of welcome messages to the user. If I go and create a custom control project to facilitate this, I will get something like:
public class WebCustomControl : WebControl
public string Text
String s = (String)ViewState["Text"];
return ((s == null) ? String.Empty : s);
ViewState["Text"] = value;
public string Text2
String s = (String)ViewState["Text2"];
return ((s == null) ? String.Empty : s);
ViewState["Text2"] = value;
protected override void RenderContents(HtmlTextWriter output)
A very basic control that is rendering two welcome messages and the user of the control has an option of setting these messages from outside, which could be from a database call or reading from a file. The user will perhaps do this only once and will expect our control to remember these
strings. So let's say the user of the controls is doing something like:
if (IsPostBack == false)
WebCustomControl_1.Text = "This is a dummy Text";
WebCustomControl_1.Text2 = "This is another dummy Text";
Now for the first run, he will do the property setting and from next time onwards, he leaves it upto the control to render these things. Now the page still has
EnableViewState property set to "
true". So if we run the page and do postback, we will observe the expected behavior. Let's look at what user will see:
Now if the user disables the
viewstate for the page or even for our custom control when a postback occurs:
The values are gone, the reason being our control depends on
ViewState to function and we need to remove this dependency to
controlState so that even in this scenario, our control will continue to work.
So let us use Control State for one line of text and not for other (purely to see how these things differ and we can compare the right way and the wrong way in the same piece of code, ideally all the controls information should use
What we need to do here is, we have to override the
OnInit method and call the
RegisterRequiresControlState method during initialization. Then we have to override the
LoadControlState methods. So let us see how we do that for using
Text property of our control.
protected override void OnInit(EventArgs e)
protected override void LoadControlState(object savedState)
Text = (string)savedState;
protected override object SaveControlState()
Now we have the first property of our control using
controlState and the second one not using it. Now on postback, the output is:
Look at the code to see the difference. The right way would be the way
ControlState is being used for the first property, it should be used for all the controls inside a custom control.
Points of Interest
To summarize, we saw what is the control state and how to enable it in custom controls. The control state takes away the decision of a developer whether to use
ViewState or not. Whenever we want to use the control state, you should think whether to implement it or give the decision of how to save the state information to the developers that use your control. The second choice is more preferable as it decreases the dependency on something that
Page can set.
- 17 Feb 2012: Explanatory tutorial on