views:

969

answers:

5

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.ToString(ViewState["Title"]); }
        set { ViewState["Title"] = value; }
    }

I can't say I'm real impressed with this though, as the more properties a user control has the more crap you'll be sticking in the ViewState. Is there a better way to persist properties?

+4  A: 

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.

Sayed Ibrahim Hashimi
Yes, the property values need to persist through a postback. I have a button in the user control which raises it's button event when clicked (duh), and it is at this time that I need to retrieve certain property values. Oh well, guess I'll just bloat the ViewState!
Jagd
"to be persisted beyond a post-back then you'll either have to use ViewState or Session". This isn't true for ViewState. ViewState only persists between post-backs, not beyond.
dariom
A: 

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

Jason
So what happens when you have two requests and they both want to use different properties on the user control?
Wyatt Barnett
+1  A: 

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.

Wyatt Barnett
+1  A: 

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.

Stefan
+2  A: 

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 :-)

dariom