ViewState Questions

[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.

[Scott M.]

"neo" <wo*@yahoo.co m> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

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.
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.

[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 SavePageStateTo PersistenceMedi um 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: [phone]
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Kevin Spencer]

Comments inline:

"neo" <wo*@yahoo.co m> wrote in message
news:#M******** ******@tk2msftn gp13.phx.gbl...

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 programmaticall y 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.

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.

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." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...

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.
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.

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.

[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.".

"Kevin Spencer" <ke***@takempis .com> wrote in message
news:uB******** ******@TK2MSFTN GP09.phx.gbl...

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." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...

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.

> 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.

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.

[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.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
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." <s-***@BADSPAMsnet .net> wrote in message
news:#2******** ******@TK2MSFTN GP09.phx.gbl... 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.".

"Kevin Spencer" <ke***@takempis .com> wrote in message
news:uB******** ******@TK2MSFTN GP09.phx.gbl...

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." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...

> 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.

> > 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.
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.

[Scott M.]

"JD" <[e-mail] > wrote in message
news:es******** ******@TK2MSFTN GP12.phx.gbl...

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.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
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.
"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:#3******** ******@tk2msftn gp13.phx.gbl...
"JD" <[e-mail] > wrote in message
news:es******** ******@TK2MSFTN GP12.phx.gbl...

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.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
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?