ViewState is similar to many ASP.Net entities in that it has a server-side
component and a client-side component. The client-side component is a hidden
form field containing the compressed values of all ViewState objects in the
Page. On the server-side, ViewState is a serializable Name-Value Collection
that is a property of each Control (each Control has and manages its own
ViewState). Because it is a public Collection, it is accessible on the
server programmatically, and you can read, add, modify, and remove elements
from the Collection.
To say that ViewState is "handled by ASP.Net" is only partially correct.
Every Control that uses ViewState manages its' own ViewState (not ASP.Net er
se). However, there are times when you may want to persist some serialzable
data across PostBacks without using Session or some other server-side
caching mechanism. By adding that data to the Page's ViewState, or any of
its Controls ViewState, you can do this. Also, you may develop your own
Server Controls, in which case you will have to write the code that manages
its ViewState.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
"Brian Shannon" <bs******@lbrspec.com> wrote in message
news:eh**************@TK2MSFTNGP09.phx.gbl...
I am curious about viewstate. I thought viewstate is pretty much handled
by ASP.NET but I have read a lot about uses of calling/retrieving values from
viewstate or saving a value to viewstate. If viewstate is managed by
ASP.NET in what cases does it need to be managed by the developer?
Does anyone have some good articles on viewstate that could better help
me?
Thanks