Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 823
  • Last Modified:

Why cannot Viewstate persist across pages ?

I have a funfdamental doubt on Viewstates.

We know from traditional ASP that we can accesshidden fields on one page in the other page.
Now for ASP wweb server controls like labels whose values might be stored in Viewstates, why cannot we access these values on other pages ? The basic question that comes to my mind is that
the Viewstate is also internally stored as __VIEWSTATE hidden field. So how is it different in its accessibility on other pages ?

Any help is greatly appreciated.
  • 3
  • 2
  • 2
  • +1
3 Solutions
Hmm ok. Think about this way. When you have a TextBox server control on a page, if you look in the Code behind file, you will see the declaration of textbox as
protected System.Web.UI.WebControls.TextBox TextBox1;

So, from another class you can instantiate this WebForm1 class and access this TextBox1 control based on its access modifiers. Thats cool, since its just another class and another class variable.

Now think about ViewState. ViewState is never stored on the server. Its stored only on the browser. So, when you load a webpage, and submits, its viewstate is submitted along with in, then your code behind file would access that viewstate and do whatever. This is fine. So, as you can see, ViewState is available only when the postback is in progress, once the post back is over, viewstate is no longer there in terms of the server. Its only on the browser. I emphasize again, its stored only on the browser.

But where as for server controls, their declaration presents on the server, so you can use them on the server or another pages code behind. But, viewstate can not be accessed unless you do postback
Viewstate is dedicated to the specific page for which it is defined.  If you are trying to pass values from one page to another, use the Session object instead.

The purpose of Viewstate is NOT to facilitate passing values between pages, but rather to hold the View State of the current page, so that that state can be preserved upon a PostBack of the page to the server, in order to handle Server Side event processing.

This is from the Microsoft MSDN page  :

"ViewState is the mechanism ASP.NET uses to keep track of server control state values that don't otherwise post back as part of the HTTP form. For example, the text shown by a Label control is saved in ViewState by default. As a developer, you can bind data or programmatically set the Label just once when the page first loads, and on subsequent postbacks, the label text will be repopulated automatically from ViewState. So in addition to less grunt work and less code, the benefit of ViewState is often fewer trips to the database.

How ViewState Works
There's really nothing magical about ViewState. It's a hidden form field managed by the ASP.NET page framework. When ASP.NET executes a page, the ViewState values from the page and all of the controls are collected and formatted into a single encoded string, and then assigned to the value attribute of the hidden form field (specifically, <input type=hidden>). Since the hidden form field is part of the page sent to the client, the ViewState value is temporarily stored in the client's browser. If the client chooses to post the page back to the server, the ViewState string is posted back too. You can actually see the ViewState form field and its postback value in Figure 2 above.

Upon postback, the ASP.NET page framework parses the ViewState string and populates the ViewState properties for the page and each of the controls. The controls, in turn, use the ViewState data to rehydrate themselves to their former state.

There are three more small, but useful things to know about ViewState.

You must have a server-side form tag (<form runat=server>) in your ASPX page if you want to use ViewState. A form field is required so the hidden field that contains the ViewState information can post back to the server. And, it must be a server-side form so the ASP.NET page framework can add the hidden field when the page is executed on the server.
The page itself saves 20 or so bytes of information into ViewState, which it uses to distribute PostBack data and ViewState values to the correct controls upon postback. So, even if ViewState is disabled for the page or application, you may see a few remaining bytes in ViewState.
In cases where the page does not post back, you can eliminate ViewState from a page by omitting the server side <form> tag. "

look at

for a more complete explanation of ViewState.

in general, FORGET (ABSOLUTELY FORGET) everything you ever knew about ASP, as it has no relevance whatsoever to ASP.NET.

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Amit01Author Commented:
Well dwelling on my issue a little further, i came up with the following thoughts -

I am not thinking of the Viewstate in terms of ASP way , but I am like trying to digest the fact that
the Viewstate is nothing but a hidden field, base 64-bit encoded and encrypted and called __VIEWSTATE. So why do we have to treat the two differently ? Now,

1. A Hidden field, say <input type="hidden" name = "testme" runat = "server">  on page1 , say
    Page1.aspx, can I access this testme on Page2.aspx ?
    If I used method = "POST" and request.form on Page2.aspx, it did not return me anything.

    Well, if you can use it, could you let me know how. Also that would lead to another question -
    When you can access "testme", why do you say you cannot access "__VIEWSTATE" in a similar  
    way, which means you are using Viewstate across pages.
    Both are hidden fields, both are input server controls.

2. If the hidden field testme cannot be accessed from page2.aspx, then that answers my question, I

WEll, the MSDN article that Arthur suggested , I went through it but besically I did not find much on hidden fields or a comparison between __VIEWSTATE field and any other hidden field.

_Viewstate is not a server control. Does the msdn saysy so. Can you please provide the links
Well Viewstate contains specific information about the controls on your page.  If you have some reason for wanting to access the viewstate you can submit the page via post to another page and then access it with the Request.Form["__ViewState"] command.  I cant think of a good reason to do this, but it is possible.
did you not read the post from MSDN that I quoted, above:

"It's a hidden form field managed by the ASP.NET page framework"  note the phrase MANAGED BY THE ASP.NET PAGE FRAMEWORK.  

This means that ViewState is NOT a normal, run-of-the-mill <hidden> field, and cannot be treated as if it were.

Stop trying to force ASP.NET into your understanding of ASP.  That will never get you anywhere.

<input type="hidden" name="__VIEWSTATE" value="/VudG...lsIG==" />

That right there is a hidden field, you CAN pass it with Request.Form["__VIEWSTATE"] I HAVE done it. Now like i just said I am doubtful that you can find any useful purpose for it, but it IS possible.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now