ViewState Questions

[Scott M.]

hi,

I am studying ASP.NET and have few questions -

1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?

2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round
trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?

ViewState is not responsible for textboxes (and many of the other standard
controls) holding on to their values after a postback. A textbox, checkbox,
radio button, password box, text area or hidden form field need no .NET
assistance to submit their data to the server (HTML Post takes care of
that). When those values arrive at the server and the server is getting the
page ready for its postback delivery back to the client, the sever just
takes the posted values and makes those values become the default values of
the controls for the trip down (i.e. <INPUT TYPE="Text" VALUE="value posted
during last rendering">).

So, for many of the "HTML-like" server controls, viewstate is not what's
responsible for them maintaining their state across postbacks.

Where viewstate would come in would be for a drop down list box. Viewstate
isn't needed to remember what from the list was chosen, it's used to
remember the whole list in the first place.

3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ?

As mentioned above, those controls that don't need viewstate because they
are using POST, don't have their values stored in viewstate to begin with.
If you turn on page tracing and look at the Control Tree section, you will
see this.

 

[Natty Gur]

In addition to Scott post,

If you really want to know what stored in the ViewState data even if you
got empty page with enableviewstate set to false you have to investigate
a little bit.
1) Override SavePageStateToPersistenceMedium method and inspect in
runtime the value of the First parameter of triplex object that pass as
parameter.

2) Follow the post in my blog on “Behind the scenes of ASPX files” and
open the class that asp.net generate for your ASPX file. Scroll to
GetTypeHashCode function and check out the return value.

Yes, this is the value that saved by the page in Viewstate.
GetTypeHashCode return hash code that is unique to the Page object's
control hierarchy.


Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377

 

[neo]

hi,

I am studying ASP.NET and have few questions -

1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?

2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round
trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?

3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ? May be this is
needed for DataGrid controls which are implemented as Table tags and these
table tags are not controls so they are not sent with the form POST. ( and
so need to be stored in VIEWSTATE ). But still why store values of all the
controls (including those which are posted with the form ) ?

4) Can session ID be made to be stored in cookies rather than the VIEWSTATE
?

May be I am missing something basic here, plz advice.
Thanks.
Pravin.

 

[Kevin Spencer]

Comments inline:

1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?

First of all, the Session ID is NOT stored in ViewState. It is stored either
in a cookie, or in URL QueryString. It is very important to discriminate
between ViewState and Session State. Session variables are stored in memory
(or in a database) on the server. ViewState stores values in a hidden form
field on the Page. Sessions time out. As ViewState variables are in the HTML
of a web document, they do NOT expire. By default, Control values (of
certain controls) are the only thing stored in ViewState. However, you can
also programmatically add variables to any Page's ViewState.

2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round
trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?

Any Control that has ViewState disabled should not be able to maintain its
State. I don't know what the problem is with your app.

3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ? May be this is
needed for DataGrid controls which are implemented as Table tags and these
table tags are not controls so they are not sent with the form POST. ( and
so need to be stored in VIEWSTATE ). But still why store values of all the
controls (including those which are posted with the form ) ?

There are any number of reasons for this. ViewState has a specific purpose,
and it is NOT for storing the CURRENT client-side value of a Control. It is
for storing the LAST value the Control had prior to PostBack. It can also be
used on the server side to find out if the value in a Control has changed
since the last PostBack, which can certainly come in handy. And so on.

4) Can session ID be made to be stored in cookies rather than the

VIEWSTATE

Since Session ID is already NOT stored in ViewState, but by default is
stored in a Cookie, this question is moot.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Scott M.]

Any Control that has ViewState disabled should not be able to maintain its

State. I don't know what the problem is with your app.

That's not true. As stated in my last post, many of the HTML-like controls
(textboxes, checkboxes, radiobuttons, etc.) don't use ViewState to hold
their values in the first place, so disabling ViewState would not affect the
control's ability to retain its state.

If you don't want a control to maintain its state, you could just use an
HTML control, rather than a Web Form control.

There are any number of reasons for this. ViewState has a specific purpose,
and it is NOT for storing the CURRENT client-side value of a Control. It is
for storing the LAST value the Control had prior to PostBack. It can also be
used on the server side to find out if the value in a Control has changed
since the last PostBack, which can certainly come in handy. And so on.

Well, again, not always. Those controls that POST their values to the
server and have an HTML mechanism for setting a default value (value="?",
Checked, etc.), don't also write their last value into ViewState. ViewState
is generally for holding the values of the more "rich" controls like
DataGrids, ListBoxes and such.

 

[Kevin Spencer]

I'm not looking for an argument. I stand by what I said.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Scott M.]

I'm not trying to give you an argument. I'm trying to point out an
erroneous statement.

Have you ever taken a Web Form textbox, set EnableViewState to False and
seen what happens? Or have you ever turned on page level tracing for a page
with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin with.
Knowing that, it is easier to understand why turning ViewState off wouldn't
affect the behavior.

I don't know how you could "stand by" your assertion that "Any Control that
has ViewState disabled should not be able to maintain its State."

But it does become clear why you would say "I don't know what the problem is
with your app.".

 

[JD]

Have you ever taken a Web Form textbox, set EnableViewState to False and

seen what happens? Or have you ever turned on page level tracing for a page
with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin with.
Knowing that, it is easier to understand why turning ViewState off wouldn't
affect the behavior.

Looking at the IL for textbox, it does indeed use viewstate.

..method public hidebysig newslot specialname virtual
instance void set_Text(string 'value') cil managed
{
// Code size 18 (0x12)
.maxstack 8
IL_0000: ldarg.0
IL_0001: callvirt instance class System.Web.UI.StateBag
System.Web.UI.Control::get_ViewState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.StateBag::set_Item(string,

object)
IL_0011: ret
} // end of method TextBox::set_Text


Does it absolutely need it? probably not. Previous values (viewstate) and
current values (post back data) are used to determine changed events. I just
did an experiment where viewstate for textbox was turned on, the text
changed event fires only when the text actually changes. Turn off viewstate,
and the text changed event fires on every postback.

JD

 

[Scott M.]

Looking at the IL for textbox, it does indeed use viewstate.

.method public hidebysig newslot specialname virtual
instance void set_Text(string 'value') cil managed
{
// Code size 18 (0x12)
.maxstack 8
IL_0000: ldarg.0
IL_0001: callvirt instance class System.Web.UI.StateBag
System.Web.UI.Control::get_ViewState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.StateBag::set_Item(string,

object)
IL_0011: ret
} // end of method TextBox::set_Text


Does it absolutely need it? probably not. Previous values (viewstate) and
current values (post back data) are used to determine changed events. I just
did an experiment where viewstate for textbox was turned on, the text
changed event fires only when the text actually changes. Turn off viewstate,
and the text changed event fires on every postback.

JD

Thanks JD. So, I guess the moral of the story is that for controls that
post their data and hold their values because the server planted the value
into the default value attribute, ViewState is used only to determine if a
change event fires?

 

[JD]

Thanks JD. So, I guess the moral of the story is that for controls that

post their data and hold their values because the server planted the value
into the default value attribute, ViewState is used only to determine if a
change event fires?

Taking a closer look, it seems like properties are saved in viewstate also.
I just set the width of textbox to 1000px in the not postback section of
page load, set viewstate off, and the textbox does not remember it. Set
viewstate to on and it can retain its width setting.

 

[Natty Gur]

Hi,

you can see exactly what saved in viewstate by overriding
SavePageStateToPersistenceMedium method and check the parameter values.

Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377