views:

1577

answers:

5

I have the following property in a custom control:

List<myClass> _items;
public List<myClass> Items{
    get { return _items; }
    set { _items= value; }
}

In my codebehind, I add items to the collection as in...

myCustomControl.items.Add(new myClass());

However, these are not persisted across postbacks. What is the proper way to allow persistance in custom controls?

+1  A: 

if you are talking about persisting the data across postbacks of the same page then you can manually add the items to the ViewState and the retrieve them On Load.

Victor
As long as List<> and myClass are marked Serializable that will work fine. If not, he'll have to override SaveViewState and LoadViewState.
Robert C. Barth
+1  A: 

You can store them in the controls viewstate

public List<myClass> Items{
    get { return this.ViewState["itemsKey"] }
    set { this.ViewState["itemsKey"]= value; }
}
Corey Downie
Again, MyClass has to be serializable to store it in ViewState.
Robert C. Barth
You must cast your return value in the get {}. ViewState is of type Object, not of type List<myClass>.
Andrew Robinson
+1  A: 

Yikes! Don't put a List<> into the ViewState! It'll be massive!

If you add a List<string> that contains two elements - "abc" and "xyz" into the ViewState, it'll grow by 312 bytes.

If instead you add a string[] that contains the same two elements, it'll only grow by 24 bytes.

And that's just lists of strings! You can put your classes in there as Corey Downie suggests, but your ViewState will mushroom!

To keep it a sensible size, you'll have to go to some effort to convert your list of items into arrays of strings and back again.

As an alternative, consider putting your objects into the Session: that way your objects will be stored on the server, instead of being serialized into the ViewState and sent to the browser and back.

teedyay
Storing the items in session is probably worse than storing them in ViewState. You now have the additional problem of requiring sticky sessions in a web farm.
Robert C. Barth
Agreed. Sessions are soooo limited (though pretty handy when you *can* use them).
teedyay
+1  A: 

I agree that there are issues with a List<> in viewstate but it does work. Note that there is no setter on this by design. You need a reference to the list object object and your get method can new up a list when needed.

protected List<myClass> Items
{
    get
    {
        if (ViewState["myClass"] == null)
            ViewState["myClass"] = new List<myClass>();

        return (List<myClass>)ViewState["myClass"];
    }
}
Andrew Robinson
+1  A: 

One way to overcome the size problem with a generic list is to persist it in ViewState as its basic array type:

protected List<string> Items 
{ 
    get 
    { 
        if (ViewState["Items"] == null)
            ViewState["Items"] = new string[0];
        return new List<string>((string[])ViewState["Items"]);
    }
    set
    {
        ViewState["Items"] = value.ToArray();
    }
}
Chris, this will work when assigning a list to the property (list.Add("abc"); Items = list;) but it will fail to persist a list that is modified using the following: Items.Add("abc"); This is not very intuitive.
Andrew Robinson