I've decided that I'm going to start blogging for blogging's sake, even if I don't have any groundbreaking material - just to get back in the habit.  Today, I start by cleaning out my comments (that took a while - yikes), and follwing the time honored tradition of making a full blog post out of linking to someone else's blog. ;)

Says Dave Reed:

It's not that there's no good information out there about ViewState, it's just all of them seem to be lacking something, and that is contributing to the community's overall confusion about ViewState. For example, one of the key features that is important to understand about ViewState is how it tracks dirtiness. Yet, here is a very good, in-depth article on ViewState that doesn't even mention it! Then there's this W3Schools article on ViewState that seems to indicate that posted form values are maintained via ViewState, but that's not true. Don't believe me? Disable ViewState on that textbox in their example and run it again). And it's the #1 Google Search Result for "ASP.NET ViewState". Can you believe that? Ok so these are all third party sites. Microsoft articles wouldn't be wrong, would they? No. But, they aren't extremely in depth either. For example, here is ASP.NET Documentation on MSDN that describes how Controls maintain state across postbacks. The documentation isn't wrong per say, but it makes a statement that isn't entirely correct:

"If a control uses ViewState for property data instead of a private field, that property automatically will be persisted across round trips to the client.

That seems to imply that anything you shove into the ViewState StateBag will be round-tripped in the client's browser. NOT TRUE!

Well, he goes on from there to disect Viewstate in great detail, and let us know how we're all coding our custom controls in Very Bad Ways (tm).  Well worth the read.