Yet, here is a very good, in-depth article on View State that doesn't even mention it! The documentation isn't That seems to imply that anything you shove into the View State State Bag will be round-tripped in the client's browser. So it's really no wonder there is so much confusion on View State.
Then there's this W3Schools article on View State that seems to indicate that posted form values are maintained via View State, but that's not true. Disable View State on that textbox in their example and run it again). There is no where I've found on the internet that has a 100% complete and accurate explanation of how it works!
The best article I have ever found is this one by Scott Mitchell. However, it does not explain the relationship of controls and their child controls when it comes to initialization and View State Tracking, and it is this point alone that causes a bulk of the mishandlings of View State, at least in the experiences I've had.
NET Framework, it's four main roles in the page lifecycle are quite distinct from each other. When writing your own controls it would usually be a good idea to follow this pattern, but thought should first be put into what should and shouldn't be allowed to be dynamically changed on postbacks. It is also important to understand how DEFAULT VALUES are implemented using this technique.
Logically, we can separate them and try to understand them individually. VIEWSTATE STORES VALUESIf you've ever used a hashtable, then you've got it. View State has an indexer on it that accepts a string as the key and any object as the value. When you think of a property that has a default value, in the traditional sense, you might imagine something like the following: Like a hashtable, the State Bag will return null as the value behind a key if it simply doesn't contain an entry with that key.
It is often the mishmash of information on View State that confuses people. For example: Actually, "View State" is just a name. Control class, from which all server controls, user controls, and pages, derive from. So if the value is null, it has not been set, so return the default value, otherwise return whatever the value is.
After a complete explanation of the entire View State process, I will go into some examples of how developers typically misuse View State, usually without even realizing it, and how to fix it.
I should also preface this with the fact that I wrote this article with ASP. However, there are very differences in the View State mechanism in ASP. For one, Control State is a new type of View State in ASP.
NET 2.0, but it treated exactly like View State, so we can safely ignore it for the purposes of this article. Web assembly, but other than it's dependency on the State Formatter, also defined in System. UI, there's no reason why the State Bag class couldn't live along side Array List in the System. In practice, Server Controls utilize View State as the backing store for most, if not all their properties. here it is a 3rd time: SERVER CONTROLS UTILIZE VIEWSTATE AS THE BACKING STORE FOR MOST, IF NOT ALL THEIR PROPERTIES.
First let me explain why I think understanding View State While View State does have one overall purpose in the ASP. Strictly speaking, the State Bag class has nothing to do with ASP. This is true of almost all Microsoft's built in controls (ie, label, textbox, button). You must understand this about controls you are using. Depending on your background, when you think of a traditional property, you might imagine something like this: What is important to know here is that this is NOT what most properties on ASP. Instead, they use the View State State Bag, not a private instance variable, as their backing store: And I can't stress it enough -- this is true of almost ALL PROPERTIES, even STYLES (actually, Styles do it by implementing IState Manager, but essentially they do it the same way).
I would like to help put an end to the madness by attempting to explain exactly how the View State mechanism works, from beginning to end, and from many different use cases, such as declared controls vs. There are a lot of great articles out there that try to dispel the myths about View State.
You might say this is like beating a dead horse (where View State is the horse, and the internet is the assailant). No, he's very much alive and he's stampeding through your living room. Don't worry, no horses were harmed during the authoring of this article.
It's not that there's no good information out there about View State, it's just all of them seem to be lacking something, and that is contributing to the community's overall confusion about View State.
For example, one of the key features that is important to understand about View State is how it . NET Documentation on MSDN that describes how Controls maintain state across postbacks.