View state

[Neven Klofutar]

Hi,

I recently read an article on MSDN about viewstate and postback.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/viewstate.asp

The author states the following:
"It is a common misconception among developers that view state is somehow
responsible for having TextBoxes, CheckBoxes, DropDownLists, and other Web
controls remember their values across postback. This is not the case, as the
values are identified via posted back form field values, and assigned in the
LoadPostData() method for those controls that implement
IPostBackDataHandler."

I would like to know exactly what ASP.NET controls don't need viewstate to
remeber value across postbacks.

thanx, Neven

 

[Karl Seguin]

Any control who's value can be deduced from Request.Form.

However, note that even in the most obvious case, such as a textbox, the
viewstate still preserves the OLD value, which is the ONLY way for
TextChanged event to fire server-side.

Also, only the _selected_ value is preserved without viewstate. This means
if you have a radiobutton list with out viewstate, not only will your
Changed event not fire, but you won't have access to the non-selected radio
buttons.

In other words, all form elements can make due with only REquest.Form...if
you've programmed in classic ASP/PHP, the meaning of this should be
intuitive.

Karl

 

[Neven Klofutar]

I see what you mean Karl, thanx !

Neven

Any control who's value can be deduced from Request.Form.

However, note that even in the most obvious case, such as a textbox, the
viewstate still preserves the OLD value, which is the ONLY way for
TextChanged event to fire server-side.

Also, only the _selected_ value is preserved without viewstate. This
means if you have a radiobutton list with out viewstate, not only will
your Changed event not fire, but you won't have access to the non-selected
radio buttons.

In other words, all form elements can make due with only REquest.Form...if
you've programmed in classic ASP/PHP, the meaning of this should be
intuitive.

Karl

 

[Karl Seguin]

In an email follow up, Neven asked me if I could be more clear since he was
still seeing the TextChanged event fire despite turning off viewstate. Here
was my response, in case it helps others:

The TextChanged event is broken under special conditions, I wasn't

very clear about this.



Create a simple page:

<form id="form" method="post" runat="server">

<asp:Textbox ID="name" Runat="server" EnableViewState="False" />

<asp:Button ID="x" Runat="server" />

</form>



with the following codebehind:

protected TextBox name;

protected Button x;

private void Page_Load(object sender, EventArgs e)

{

name.TextChanged += new EventHandler(this.name_TextChanged);

x.Click += new EventHandler(this.x_Click);

}

private void name_TextChanged(object sender, EventArgs e)

{

Trace.Write("TextChanged");

}

private void x_Click(object sender, EventArgs e)

{

Trace.Write("ButtonClicked");

}



Enter text and click on the button, "TextChanged" WILL fire. However, now

CLEAR the text from the textbox and hit the button, "TextChange" WILL NOT

fire. Because the old value isn't preserved in viewstate, ASP.Net assumes

that the "old" value is blank. That means that textChanged won't fire if

you go from a value to a blank one (even though the value has changed).

Also, if you enter text, say "aa" and hit the button, the hit the button

again, you'll see that TextChanged fires. That's because it's comparing the

2nd "aa" to blank, instead of the old value which is actually also "aa".

Hope that makes some sense



The problem with the radio button list is for code like this:

private void Page_Load(object sender, EventArgs e)

{

if (!Page.IsPostback)

{

rad.DataSource = "XX";

rad.DataBind();

}

x.Click += new EventHandler(this.x_Click);

}

private void x_Click(object sender, EventArgs e)

{

Trace.Write(rad.Items[0].Value); //won't work unless 0 was selected

if viewstate is off for radiobutton list

}



The problem is that values are only added when it isn't postback

(!Page.IsPostBack). With viewstate on, no problem because the control is

re-created from viewstate, with it off however, it isn't recreated, and only

the selected value can be retrieved via Request.Form("rad"). One solution

is to re-bind the control, on postback as well (remove the check for

!PAge.IsPostback). you have to decide what you prefer, fetching the data

source again (might involve a database hit) or loading the data into

viewstate? I often prefer to reload the data, especially if it's cached!



Karl