Keep countries off viewstate

Published 16 March 05 02:58 PM | despos

Imagine your page includes a drop-down list control filled with 300 country names. Do you think it will be persisted across postbacks? To this question, my answer would be NO. Wrong. The right answer is true. And where do you think all that stuff is stored across postbacks? In the viewstate, of course.

You may have heard (from me, for example) that data-bound controls don't persist their data source to the viewstate. For list controls (drop-down, checkboxlist, listbox), this is not exactly true. When you call DataBind on any of these, the data source is broken into pieces and loaded into the Items collection. And the Items collection is persisted to the viewstate.

To save your pages something like 10KB of viewstate per each country-list control in the form, you have to:

  1. Disable the viewstate for the control
  2. Retrieve the list of country from the cache and bind

You still have one problem left--the index of the selected item is lost across postback. This is another weird thing of list controls. The SelectedIndex property is NOT explicitly persisted to the viewstate and is NOT set out of posted data (the whys of this are currently beyond me). The property takes its value from the Selected property of the Items collection. As you can easily figure out, SelectedIndex is then implicitly persisted to the viewstate. That's why it gets lost across postbacks.

Workarounds? Just one--resort to the old fashioned but still effective Page.Request["countrylist"]. In Page_Load, it just returns the text of the selected item. Map that to an index position and you're done.

 

Comments

# Sergio Pereira said on March 16, 2005 09:24 AM:

+1 for ControlState in v2.0.
I think the reason SelectedIndex is not in the ViewState is that it can be changed by the user prior to the postback. This property has to be "calculated" after the ViewState of the control is restored (if enabled) and the postback data is received. Then the control can do what you suggested in the workaround: find the item in the restored Items collection and populate the SelectedIndex (and SelectedItem) properties. The control does store some infomation regarding the currently selected item, otherwise it would not be able to raise the SelectedIndexChanged event.
But I feel that same pain every day: enabling the ViewState in listcontrols with many items is a very high price to be paid just to get the SelectedItem and SelectedIndexChanged to work.
Did I say I can't wait for v2.0 ?

# Paul Wilson said on March 16, 2005 10:13 AM:

There's a much easier work-around -- rebind your list in the Init event ! This is simple page life-cycle stuff -- the posted value is restored immediately before the Load event, so you must get your values back in the list at an earlier stage. Another option, not my recommendation but necessary for some cases where your list is itself dynamically created based on some criteria you've stored in ViewState, is to rebind your list in an override of LoadViewState.

# Dave said on March 16, 2005 10:38 AM:

I would go for manually setting the index off of the Request object. Its easy. ASP.Net sure can make very simple things very complex.

# Scott Mitchell said on March 16, 2005 01:57 PM:

300 listitems! Bah, try 12,500! THEN you're talking about a big viewstate! :-)
http://scottonwriting.net/sowblog/posts/1579.aspx

# Scott Galloway said on March 16, 2005 04:51 PM:

Or keep viewstate away from the browser...sometimes ViewState is just to convenient / hard to avoid. Server side Viewstate storage is certainly a viable option then...

# Diego Mijelshon said on March 16, 2005 07:19 PM:

Scott G,
That would get rid of one problem, only to get into a really bigger one... :-)

# TrackBack said on March 23, 2005 05:42 AM:
# TrackBack said on April 1, 2005 06:42 AM:

Leave a Comment

(required) 
(required) 
(optional)
(required)