User control (ascx) and properties

Question

The only way I\'ve found to persist property values within a user control is to use the ViewState.

public string Title {
        get { return Convert.ToStrin         


        

Answer 1

You can always override the intended SaveViewState/LoadViewState methods:

public string Title { get; set; }

And then save and load as required:

protected override object SaveViewState()
{
   // Save State as a cumulative array of objects.
   object baseState = base.SaveViewState();

   object[] allStates = new object[2];
   allStates[1] = _title;
   return allStates;
}

protected override void LoadViewState(object savedState)
{
   if (savedState != null)
   {
      // Load State from the array of objects that was saved during SavedViewState.
      object[] myState = (object[])savedState;
      if (myState[0] != null)
         base.LoadViewState(myState[0]);

      if (myState[1] != null)
         _title = (String)myState[1];
   }
}

Answer 2

have you tried static properties? also, remember that http is stateless, so you may just reset your title on each page_load

Answer 3

Your problem is exactly what ViewState is for: To persist properties of a control across postbacks, so your solution is just fine.

You could save it in session, but that really just puts the burden on the server. Depending on the number of users you have, this could get really ugly really quickly.

Also keep in mind that you have to do some housekeeping if you use session. For example, if you want to use your user control twice on the same page, you need to make sure that each control uses unique session variables.

Answer 4

There's no problem at all with using ViewState to store property values for a user control.

Your statement "the more properties a user control has the more crap you'll be sticking in the ViewState" isn't necessarily true though. It's certainly possible to have ViewState track values of properties for controls but not store data in the __VIEWSTATE hidden form field variable.

Sounds crazy right? See TRULY Understanding ViewState for a brilliant article about how ViewState works.

It depends on when you initialize the properties of your controls in it's lifecycle. ViewState will only be stored in the hidden __VIEWSTATE field after the StateBag for a control starts tracking changes to property values. This happens in the OnInit method for a control which is early in the lifecycle, but there are techniques to set your property values earlier that won't incur the cost of __VIEWSTATE bloat and will still give you all the benefits.

See the linked article. It discusses everything very clearly and better than I can :-)

Answer 5

It's not too bad--that is pretty much exactly how the built-in controls work and generally will lead to expected behavior. Best bet is to just selectively disable ViewState when you don't need to persist these values across postbacks.

You also might want to look into ControlState--it is a separate "bag" that people can't disable, and is used for stuff like the GridView where there are some things that one can't turn off via viewstate because it breaks the control.

Answer 6

It depends. If you need to property values to be persisted beyond a post-back then you'll either have to use ViewState or Session. Since those controls are re-created on each post back you can't really maintain that state otherwise.