Gil Fink, Microsoft MVP, is an expert in Web development and Microsoft data platform. He works as a senior architect at Sela Group. He is currently consulting for various enterprises and companies, where he architects and develops Web and RIA-based solutions. He conducts lectures and workshops for developers and enterprises who want to specialize in infrastructure and Web development. He is also a co-author of several Microsoft Official Courses and training kits. You can read his publications at his blog: Gil is a DZone MVB and is not an employee of DZone and has posted 147 posts at DZone. You can read more from them at their website. View Full User Profile

ASP.NET - Client Side State Management - Control State

  • submit to reddit

In this post I'm going to explain what is the control state and how to use it as a part of the ASP.NET client side state management. You can read my previous posts in the state management subject in the following links:

What is Control State?

The control state is a way to save a control’s state information when the EnableViewState property is turned off. Unlike ViewState a developer can’t turn off control state. The control state can be implemented only in controls that you implement.

How to Use Control State?

Control state implementation is easy. First, override the OnInit method of the control and add the call for the Page.RegisterRequiresControlState method with the instance of the control to register. Then, override the  LoadControlState and SaveControlState in order to save the required state information.

The next example shows a simple implementation for a control that saves a string as a state information:

public class ControlStateWebControl : Control
#region Members

private string _strStateToSave;

#region Methods

protected override void OnInit(EventArgs e)

protected override object SaveControlState()
return _strStateToSave;

protected override void LoadControlState(object state)
if (state != null)
_strStateToSave = state.ToString();



You need to remember only one thing – the control state takes away the choice to disable ViewState. You should
only use it whenever you have to keep a state information that without it your control won’t work. 


To sum up the post, I showed what is the control state and how to enable it in your controls. The control state takes away the decision of a developer whether to use ViewState or not. Whenever you 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. I prefer the second choice. In the next post in this series I’ll start to explain the server side state

Published at DZone with permission of Gil Fink, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


DLink Wow replied on Thu, 2008/10/16 - 11:07pm

To save multiple properties into Control State:
private int _prop1;
public int Prop1
    get { return _prop1; }
    set { _prop1 = value; }

private string _prop2;
public string Prop2
    get { return _prop2; }
    set { _prop2 = value; }

protected override object SaveControlState()
    object[] state = new object[2]; // save the 2 properties
    state[0] = _prop1;
    state[1] = _prop2;

    return state;

protected override void LoadControlState(object savedState)
    object[] state = (object[])savedState;
    _prop1 = (int)state[0];
    _prop2 = (string)state[1];

Gil Fink replied on Fri, 2008/10/17 - 7:03am in response to: DLink Wow

Hi dlink22,
Thanks for sharing that code.
You can do it without an array and with an internal class which you can call [NameOfTheControl]State and will hold all the relevant properties. I prefer that solution because I don't like to hard code indexes and it's more elegant. Also, as I wrote I prefer if I can to minimize the number of properties that I save in the control state in order to give the users of the control more flexibility.   

snives snivess replied on Tue, 2008/10/21 - 8:55pm

@Gilf, I read the description of how you prefer to store controlstate and decided to test it out for myself.  Here are the results of my findings:

When using a composite class to persist your objects the ObjectStateFormatter takes the composite class/struct stores it in viewstate.  But before that it checks its type to see if there is a special optimization for that object type.  Since it is a custom object it doesn't do any optimization and simply serializes it, but it also needs to include the fully declared name of the object it is serializing!  *This* actually results in the opposite behavior than what you are trying to do, optimize viewstate.  In a test app storing two GUIDs in a structure instead of a Pair object, the viewstate was 348 bytes larger than the optimized Pair version.  Thats alot of overhead for what could essentially be stored in 78 bytes.

As I eluded to above the ObjectStateFormatter has special optimizations for certain types, which can be found here  If you are storing control state, then there is really hardly reason to store more than 1 or 2 variables, which are usually keys anyhow.  If you only have 1 variable just return it.  If you have 2 use a Pair object.  If you have 3 there is even a Triplet object.  If you have 4 or more, then use an object array, as this article shows.

I am all for simplicity and elegance as well, but in this case the more elegant approach is actually causing us a viewstate bloat problem.  And since the Object[] is loaded and saved within the same class, there really isn't any downside to using it.

Gil Fink replied on Wed, 2008/10/22 - 1:40am in response to: snives snivess

Hi snives,
As you wrote, I prefer the elegant way but in the control state case, as you mentioned, this will cause us a viewstate bloat problem (I checked it after I read your comment). 
Thanks for your insight. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.