Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request.
I've seen a lot of *elegant* solutions on how to solve this. All these examples proving it out what have you.
I can't beleive Microsoft would hose us over with such a thing!!!
Well, they didn't... Hello ViewStateModeById !
How does it work? Reflect it, what you'll find is that it simply iterates through the control tree by name instead of the index version which iterates through the tree (for each INamingContainer ) and then takes a value at the same index position in the ViewState statebag. This is highly efficient, and with the way web forms are typically used, it works.
The counter to the ViewStateByModeId is performance. But look at most of the dynamic control ViewState problem solving methods out there. You'll find a great many simply use the same method to find the name of the control in the control tree. If you consider the general computing power of modern servers, the performance impact is negligible. There are edge cases where you have massive control trees, but if so, it might be a good idea to look at your overall page structure and other optimizations. Don't blame it on the ViewState.
Not only that, they implemented it as both a property on Control and an Attribute. Remember that Page is inherited from Control, so OnInit, just set the property first, then add your controls here not in Page_Load. The lifecycle has already passed the LoadViewState event.
There is one gotcha. It does not quite work correctly on radio groups, so you have to request the value from the Form in order to set it, get values.
One line of code that has saved me more hours and that much frustration than is fathomable. Hope you get the same. Time to cross post the hell out of this.
You're welcome ;)
