Can I avoid having an UpdatePanel that kills viewstate?

Question

I selection page that has a gridview that presents the user with a list of data items that they can click on to "drill into" - redirecting them to the data maintenance page.

Because the list can get long, we have a series of check boxes and drop-down lists at the top that act as filters.

We just implemented an UpdatePanel with an UpdatePanelAnimationExtender so that when the page made long trips back to the databse, they would get a nice "Processing..." pop up.

Problem is, this seems to break the viewstate on the drop-down lists and check boxes. Now, when they go to the 'detail page' and hit the BACK button to get back to the 'selection' page - the selected values in the checkboxes and drop-downlists are back to their initial defaults. The lists are still populated, but they 'forgot' what they had when the user clicked to the data maintenance page.

I took out the .aspx code for the UpdatePanel and the animation extended and retested and everything worked perfectly. So, apparently, the UpdatePanel and/or the AnimationExtender doesn't play nice with the viewstate.

Is there a way I can stop the UpdatePanel's actions from, in effect, zeroing out the '.SelectedValue" properties?

Answer 1

First I would remove your "filtering" controls from the UpdatePanel. Assuming that the data for these controls are valued on Page_Load, they do not need to be refreshed every time the filter is applied to the GridView. Only the GridView is being refreshed, so it's likely that it is the only control that should be contained in the UpdatePanel.

Each of the filtering controls can be added as a trigger for updating the UpdatePanel by declaring them in the section of the UpdatePanel control. Or, if the filtering process is invoked by a "submit" like button, that would be the control to be declared in the section. This should retain the values of the filtering controls in the browser's cache.

You can also try Nikhil Kothari's UpdateHistory control (Nikhil has an excellent blog, btw) which will save the contents of the UpdatePanel as history entries in the browser's history list.

EDIT: FYI, UpdatePanel does not "kill" ViewState. The ViewState is transmitted back and forth via the UpdatePanel's update mechanism, often causing performance issues if the ViewState is excessively large. What you're seeing is the browser's history cache not storing the values that have been updated on successive callbacks. The above techniques should help.