By now, every good control developer knows that you implement a public property using ViewState. Heck I have a macro for adding viewstate-backed properties, that turns:

String Foo ““

into

public virtual String Foo {
  get {
    Object savedState = ViewState[“Foo“];
    if ( savedState != null ) {
      return (String)savedState;
    }
    return ““;
  }
  set {
    ViewState[“Foo“] = value;
  }
}

The viewstate is a great mechanism for storing your control properties, but it has a flaw/disadvantage. Consider what the EnableViewState property does, and how it affects controls. When EnableViewState is set to false, there's no difference between a property that doesn't matter too much, such as BackColor, and properties that are vital to the workings of the control, such as a CurrentPanel property, which might control which panel is shown on a multi-panel control. Without storing which panel is currently shown, there's no way to raise a mythical CurrentPanelChanged event, because the one being sent in the form post has to be compared with the previous, and you won't have the previous value because ViewState is disabled.

So now enters ControlState. This is another “hidden input based round trip state keeper” like ViewState. However, it is meant for storing these vital properties, so that your control is still functional when viewstate is disabled. So while BackColor, FontSize, and their friends can still be stored in the unreliable ViewState, Really Important© properties can go in ControlState, so the control can do the basic things that it says it does, regardless of other factors.

It's not quite as easy to use as viewstate, as there's no StateBag to throw things into. You have to override LoadControlState and SaveControlState, as well as notify the page that you need ControlState, with the obligatory Page.RegisterMeForDoingSomethingOutOfTheOrdinary method.

But easy or not, it's useful and puts more power in the hands of control developers, and that's all it takes to make my List Of Control-Developery Happiness©.

I thought I might mention the one downside to this new mechanism. The problem is going to be in deciding on what is important enough to go into ControlState, and what isn't. I can imagine these battles between page developers trying to keep their bandwidth down ( which is the intention of EnableViewState=false), and control developers trying to ensure their controls do what the docs say they do. But overall, I think it's good to have the choice.