12 Years
Discussion Span
Last Post by Reham Ejaz

Viewstate "lives" in a hidden variable embedded within the form. Thus, it is resident client-side. While the user is looking at the page, the ASP.NET application isn't "running". Thus, Viewstate doesn't exist at all.

When the users posts the form, IIS/ASP.NET go through a series of steps, one of them being the re-building of the state-bag (ViewState) from the HTTP Request object (remember, Viewstate is a hidden form variable, so is posted in the Request).

The Page Life-Cycle goes on, eventually calling any event handlers, and building the Response. This includes re-packaging the NEW Viewstate into the hidden variable. The Response is shipped back to the client, and your application goes back into non-existence until the user posts again.

Thus, ViewState only "lives" as long as it takes your application to generate a Response.


Also... Viewstate does not store the "vaules of... controls". The HTTP Request mechanism does that.

Well, that's almost right. Let's say that Viewstate does not store the value of Form Elements. What it does is store the "state" of any controls that have had their attributes altered server-side. For example say you use an ASP.NET Label control, with an initial setting. In response to some event, you change the value of that Label. The Viewstate mechanism would be used to transport that new value to the client.


Very Impressive. Then why do we use The ViewState object as it loses any information as soon as we move to any other page within the same site?

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.