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?

Because Viewstate is scoped to that particular "instance" of that particular page. It has no relevance whatsoever to another page within that application. If you need to maintain some value across the application, you'd use the Session object instead.

I explain ViewState here: http://www.tgreer.com/aspnet_html_02.html

I explore ViewState, Session, the ASP.NET Page Life Cycle, and conditional dynamic controls in this article: http://www.tgreer.com/aspnet_html_04.html

Thanks