another problem with viewstate

  • Thread starter Thread starter AlexC
  • Start date Start date
A

AlexC

Hi,

i have just read some threads about viewstate and wanted to test myself. But
there must be something i don't undertstand, because when i submit the form
with EnableViewState="false", i get the values back.
It seems that EnableViewState="false" has no influence because 'false' or
'true', it does not make any difference.
I thought that with 'false', i wouldn't get the values back.

Please look at the code here:
Thanks you
AlexC


<%@ Page Language="VB" EnableViewState="false" AutoEventWireup="false"
CodeFile="test.aspx.vb" Inherits="test" %>

<form id="frmViewState" runat="server">

Typ your name:
<asp:TextBox id="txtName" runat="server" />
Take a color:
<asp:DropDownList id="ddlColor" runat="server">
<asp:ListItem>Red</asp:ListItem>
<asp:ListItem>Blue</asp:ListItem>
<asp:ListItem>Yelowl</asp:ListItem>
</asp:DropDownList>
<asp:button id="btnSubmit" text="submit"
onClick="btnSubmit_Click" runat="server" />
</form>

the code is:
Sub btnSubmit_Click(ByVal Sender As Object, ByVal E As EventArgs)
lblSentence.Text = txtName.Text & " selecteerde " _
& ddlColor.SelectedItem.Text
End Sub
 
a controls render properties are stored in viewstate, but the postback
values are sent as seperate form item along with viewstate.

viewstate is loaded in oninit before the postback data is read. this
sets a controls properties to the render value as opposed to the
declared value.

in a textbox this allows the onchange to tell if the postback vlue is
different than the original value. you can still get onchange to work
without viewstate by saving in session the render value, and setting the
controls value in oninit to the saved value.

in dropdownlist, the items are stored in viewstate. if viewstate is
turned off and the items are loaded in codebehind rather than on the
page, they must be re-addded in the onint.

-- bruce (sqlwork.com)
 
the view state is not responsible for having TextBoxes, CheckBoxes,
DropDownLists, and other Web controls remember their values across postback.
so whether you set false or ture to the viewstate property you can get the
value back.
 
Thanks both for your explanation, and forgive me if i'm not sure to
undertsand everything, but then, if the viewstate is not responsible for
rememberng their values, for what is viewstate well responsibel then in this
present case?
 
Thanks both for your explanation, and forgive me if i'm not sure to
undertsand everything, but then, if the viewstate is not responsible for
rememberng their values, for what is viewstate well responsibel then in this
present case?
Click to expand...

The viewstate stores a list of properties for all of the controls on a
page so that these properties can be repopulated automatically when a
page is displayed after postback. Viewstate is not responsible for
posting the form values during the postback, i.e. you would be able to
access the value of any inputs on the page with postback enabled.

An excellent article on viewstate can be found at:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

If you are unsure about any aspect of viewstate this is well worth a
read and also has information on helping to reduce overhead on
viewstate
 
Thanks

phvfl183 said:
The viewstate stores a list of properties for all of the controls on a
page so that these properties can be repopulated automatically when a
page is displayed after postback. Viewstate is not responsible for
posting the form values during the postback, i.e. you would be able to
access the value of any inputs on the page with postback enabled.

An excellent article on viewstate can be found at:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

If you are unsure about any aspect of viewstate this is well worth a
read and also has information on helping to reduce overhead on
viewstate
Click to expand...
 
Back
Top