ViewState questions

[et]

I'm not sure I understand the use of the ViewState.

Do I understand correctly that values of controls are automatically held in
a hidden control called ViewState?

If so, then why can't we get them, or how do we get that value? I always
have to set the ViewState("FirstName") = txtBox.text myself before a
postback is done, otherwise, the value of ViewState("FirstName") is always
empty; there doesn't seem to be a way to retrieve that information when
needed unless manually set.

If I am setting the value of the ViewState myself, then aren't I doing
duplicate work if the value of the control should already be held somewhere?
And doesn't that meant that this hidden control is taking up resources when
it's unretrieveable, so why use it.

Is it more likely that the ViewState is just like the Session, except it
lasts for only a page, and is lost when the page changes.

And if so, does that mean there is a viewstate sitting there taking up
resources that we can't get. Should I turn it off on each control, and then
manually set ViewState myself?

Thanks for all your help, I've read an awful lot of articles already but if
you find a good one, let me know.

 

[Guest]

ViewState("FirstName") = txtBox.text means you add your own data to
ViewState. You needn't do anything if you use txtBox.ViewState("Text").

 

[Jason Penniman]

Microsfot has some good articles on ViewState, Visual Studio magazine does
as well...but here's some simple answers to your questions...

I'm not sure I understand the use of the ViewState.

Do I understand correctly that values of controls are automatically held
in a hidden control called ViewState?

A: Yes, as long as the EnableViewState propery is set to True

If so, then why can't we get them, or how do we get that value? I always
have to set the ViewState("FirstName") = txtBox.text myself before a
postback is done, otherwise, the value of ViewState("FirstName") is always
empty; there doesn't seem to be a way to retrieve that information when
needed unless manually set.

A: You can, but "FirstName" clearly is not the name of the control
"txtBox". However, you shouldn't ever need to access values for a control
from ViewState. Make sure it's and ASP Web Control with "runat" set to
server. It needs to be a server control to work with viewstate.

If I am setting the value of the ViewState myself, then aren't I doing
duplicate work if the value of the control should already be held
somewhere? And doesn't that meant that this hidden control is taking up
resources when it's unretrieveable, so why use it.

A: Well, the control is saving to ViewState if it's setup properly. To
answer your question, yes, if you have a hidden control to store a value and
you store the value yourself in ViewState, then you are duplicating efforts.
Because the webcontrol is already designed to work with ViewState and the
postback functionality, it's best practice to take the hidden control
approach. Less hand rolling of code.

Is it more likely that the ViewState is just like the Session, except it
lasts for only a page, and is lost when the page changes.

A: Correct... very similar to a Session variable, but at the page
level. It keeps you from using memory on the server and solves the client
cookies problem. It's much more powerful than that, however. To duplicate
it's fucntionality in classic ASP, a devloper would have to write hundreds
of lines of code, manage cookies, session objects, and state. Now, ASP.NET
does it all for you.

And if so, does that mean there is a viewstate sitting there taking up
resources that we can't get. Should I turn it off on each control, and
then manually set ViewState myself?

A: Yes and no. The ViewState is being used, and the only resources it
uses is band width...it makes the resulting html larger. If you don't need
ViewState for a particular control, then yes, you should disable it.

 

[bruce barker]

ViewState is used to maintain state between a render and a postback, and
indead its stored in a hidden field. any control can store any needed state
information in viewstate. some controls will honor the enableviewstate
property. most control do not need to store their value in viewstate, as the
browser will post it. a control like the datagrid, which render html, and
gets no postback data, needs to store a lot of info in viewstate - the value
of every cell.

-- bruce (sqlwork.com)






| I'm not sure I understand the use of the ViewState.
|
| Do I understand correctly that values of controls are automatically held
in
| a hidden control called ViewState?
|
| If so, then why can't we get them, or how do we get that value? I always
| have to set the ViewState("FirstName") = txtBox.text myself before a
| postback is done, otherwise, the value of ViewState("FirstName") is always
| empty; there doesn't seem to be a way to retrieve that information when
| needed unless manually set.
|
| If I am setting the value of the ViewState myself, then aren't I doing
| duplicate work if the value of the control should already be held
somewhere?
| And doesn't that meant that this hidden control is taking up resources
when
| it's unretrieveable, so why use it.
|
| Is it more likely that the ViewState is just like the Session, except it
| lasts for only a page, and is lost when the page changes.
|
| And if so, does that mean there is a viewstate sitting there taking up
| resources that we can't get. Should I turn it off on each control, and
then
| manually set ViewState myself?
|
| Thanks for all your help, I've read an awful lot of articles already but
if
| you find a good one, let me know.
|
|

 

[et]

There is no txtBox.ViewState in the intellisense list... Any other ideas??

 

[et]

This is some great information, thanks! But I still don't understand how
you get information from the view state??? Why have it if you can't get it?

A: You can, but "FirstName" clearly is not the name of the control
"txtBox". However, you shouldn't ever need to access values for a control
from ViewState. Make sure it's and ASP Web Control with "runat" set to
server. It needs to be a server control to work with viewstate.

Okay, why have a viewstate if you can't get the value of controls for
them??? During a postback, the text that a user enters in a textbox, or
even if it's hardcoded, is lost unless you retrieve it from somewhere. If I
do
dim x as String = ViewState(txtBox.text)


on postback, x is nothing, but I know there had been a value in the textbox
before the postback, so I need to get the value of that textbox.

 

[Ciaran]

You dont need to get the information from the viewstate. The control will
save its state to the viewstate and load it from the viewstate. A serverside
textbox should have the text property populated in a postback because it
does it itself.

Ciaran

 

[Jeff Evans]

This is some great information, thanks! But I still don't understand how
you get information from the view state??? Why have it if you can't get
it?

The Viewstate data for a TextBox is hidden from the parent control because
quite simply, the parent doesn't need to know about it. That's the essence
of object oriented design - hide away the implementation details from
classes which don't need to know about them.

Okay, why have a viewstate if you can't get the value of controls for
them??? During a postback, the text that a user enters in a textbox, or
even if it's hardcoded, is lost unless you retrieve it from somewhere. If
I do
dim x as String = ViewState(txtBox.text)
on postback, x is nothing, but I know there had been a value in the
textbox before the postback, so I need to get the value of that textbox.

A TextBox's Text property has nothing to do with Viewstate (unless you're
concerned with the TextChanged event, in which case the Viewstate will store
the *previous* value of Text). Whenever you have a TextBox on a form, fill
it out, and submit the form, the Text property will be populated
automatically via Postback, as long as:

1) The TextBox has been created and added to the Controls collection or a
control in the Controls collection, etc.
2) The TextBox has been added before Postback data is loaded (during Init is
best, Load might work somtimes, but it's technically late)
3) The TextBox is given the same ID each request

If your TextBox has ID "txtBox", and these three conditions are met, then
you can retrieve the Text property of a TextBox (in, say, the Load or
PreRender events) by:

string txt = txtBox.Text;

Does that make sense?