Hmmm… I'm reviewing a few additional issues in the wwHoverPanel control dealing with POST data to the server.
Everything works fine when the data is posted back to the server using a non-containership setup:
http://www.west-wind.com/presentations/wwhoverpanel/sample/HoverList.aspx
This callback posts back the content of the page including ViewState and this works Ok. You can access the chkFullInvoice checkbox directly from your code as if it were a real postback. Great.
But if you now basically do the same thing on a page that hosts a MasterPage control, you end up with major ViewState corruption.
http://www.west-wind.com/presentations/wwhoverpanel/sample/HoverList.aspx
ASP.NET now complains about ViewStateMac being invalid (Note you'll get a yellow screen of death – but it's a ViewStateMac error). The page is calling back on itself to do the callback. I'm not sure why ViewState gets bombed like this just because the containership hierarchy changed.
Worse, I can't seem to make this error go away even if I turn EnableViewStateMac and EnableEventValidtion to false. There really ought to not be any further checking for ViewState validation, but it does…
I can work around this by not posting ViewState back (which is one of the options on the control after all) and reading the values out directly with:
CheckValue = Request.Form[this.chkFullInvoice.UniqueID];
In reality in almost all situation it's better to use the explicit syntax anyway as it exerts less pressure on the page pipeline, but I still don't quite understand why ViewState is having this fit on the containership hierarchy. After all other than the hierarchy there's no difference between the first and second page.
Anybody have any ideas?
Other Posts you might also like