some text about viewstate that I don't understand

[Tony Johansson]

Hello!

Here is the text.
"One technique to store state on the client is to use ViewState. ViewState
is used automatically by the Web server control to make events work. The
ViewState contains the same state as the control when sent to the client.
When the browser sends the form back to the server, the ViewState contains
the original values, but the values of the control that are sent contains
the new values. If there's a difference, the corresponding event handlers
will be invoked."

Here is an example how the ViewState works.
Assume that you have a label and two buttons.
The label.text is initialized with "StartInit""
One of the buttons is called ChangeMessage and the other button is called
EmptyPostback
Assume that you use the default which is EnableViewState="true"
The ChangeMessage has an eventhandler.In this eventhandler you change the
label.text = "newChange"
If you now run the WebSite and click on EmptyPostback nothing happens
because this only cause a postback without any executing any code.
If you now click on the ChangeMessage the label on the browser is displayed
as newChange and if you click on EmptyPostback the newChange is still being
displayed in the browser.

Now if you set EnableViewState="false" and run the WebSite you will get a
different result.
If you click on EmptyPostback nothing happens because only a postback is
sent but no code is being executed.
If you click on ChangeMessage the label is displayed as newChange and if you
not click on EmptyPostback the label is changed back to StartInit because
the ViewState is not saved.

So as a summary I can't figure out what the text mean with this text "When
the browser sends the form back to the server, the ViewState contains the
original values, but the values of the control that are sent contains the
new values. If there's a difference, the corresponding event handlers will
be invoked."

I mean that setting EnableViewState="true" only save property changes as in
the example I gave.

//Tony

 

[Jeff Johnson]

So as a summary I can't figure out what the text mean with this text "When
the browser sends the form back to the server, the ViewState contains the
original values, but the values of the control that are sent contains the
new values. If there's a difference, the corresponding event handlers will
be invoked."

I mean that setting EnableViewState="true" only save property changes as
in the example I gave.

Example: You have 5 check boxes. Box #3 is currently checked. The ViewState
data that is sent to the browser contains within it something like this:

checkBox3.Checked=true

Now you uncheck the box and do a postback. The server will be sent the
ViewState that it handed to the browser (in other words, ViewState is
round-tripped unchanged) and it will also be sent the current values of the
form fields, one of which will look like this:

checkBox3.Checked=false

View state processing will take place on the server and it will see that the
value of checkBox3.Checked has changed (that is, the "live" version sent
back with the form differs from the "last" version stored in ViewState) and
as such it will raise the CheckChanged event for checkBox3.

I'm not entirely sure what you're confused about, so if I didn't answer the
question you asked, can you please rephrase it?

 

[Tony Johansson]

Good explained Jeff !

//Tony

Example: You have 5 check boxes. Box #3 is currently checked. The
ViewState data that is sent to the browser contains within it something
like this:

checkBox3.Checked=true

Now you uncheck the box and do a postback. The server will be sent the
ViewState that it handed to the browser (in other words, ViewState is
round-tripped unchanged) and it will also be sent the current values of
the form fields, one of which will look like this:

checkBox3.Checked=false

View state processing will take place on the server and it will see that
the value of checkBox3.Checked has changed (that is, the "live" version
sent back with the form differs from the "last" version stored in
ViewState) and as such it will raise the CheckChanged event for checkBox3.

I'm not entirely sure what you're confused about, so if I didn't answer
the question you asked, can you please rephrase it?

 

[Tony Johansson]

Example: You have 5 check boxes. Box #3 is currently checked. The
ViewState data that is sent to the browser contains within it something
like this:

checkBox3.Checked=true

Now you uncheck the box and do a postback. The server will be sent the
ViewState that it handed to the browser (in other words, ViewState is
round-tripped unchanged) and it will also be sent the current values of
the form fields, one of which will look like this:

checkBox3.Checked=false

View state processing will take place on the server and it will see that
the value of checkBox3.Checked has changed (that is, the "live" version
sent back with the form differs from the "last" version stored in
ViewState) and as such it will raise the CheckChanged event for checkBox3.

I'm not entirely sure what you're confused about, so if I didn't answer
the question you asked, can you please rephrase it?

I just tested with one checkbox and it doesn't work at all as I had
expected.
1. I set EnableViewState="false"
2. The status of the checkbox from the beginning is checked
3. I created an event handler for the checkbox with name
CheckBox1_CheckedChanged
4. I uncheck the checkbox in the browser when the website is running
5.I clicked the EmptyPostback button and when I did that the Page_Load is
called first and then is the CheckBox1_CheckedChanged called.
This was very surprising for me.The ViewState is not saved because I had set
ViewState="false" so how is it possible that
the CheckBox1_CheckedChanged is called. So my understanding from your mail
is that the CheckBox1_CheckedChanged should not be called when I have
disabled the ViewState as I had done.

Can somebody explain this ?

//Tony

 

[Arne Vajhøj]

Here is the text.
"One technique to store state on the client is to use ViewState. ViewState
is used automatically by the Web server control to make events work. The
ViewState contains the same state as the control when sent to the client.
When the browser sends the form back to the server, the ViewState contains
the original values, but the values of the control that are sent contains
the new values. If there's a difference, the corresponding event handlers
will be invoked."

Here is an example how the ViewState works.
Assume that you have a label and two buttons.
The label.text is initialized with "StartInit""
One of the buttons is called ChangeMessage and the other button is called
EmptyPostback
Assume that you use the default which is EnableViewState="true"
The ChangeMessage has an eventhandler.In this eventhandler you change the
label.text = "newChange"
If you now run the WebSite and click on EmptyPostback nothing happens
because this only cause a postback without any executing any code.
If you now click on the ChangeMessage the label on the browser is displayed
as newChange and if you click on EmptyPostback the newChange is still being
displayed in the browser.

Now if you set EnableViewState="false" and run the WebSite you will get a
different result.
If you click on EmptyPostback nothing happens because only a postback is
sent but no code is being executed.
If you click on ChangeMessage the label is displayed as newChange and if you
not click on EmptyPostback the label is changed back to StartInit because
the ViewState is not saved.

So as a summary I can't figure out what the text mean with this text "When
the browser sends the form back to the server, the ViewState contains the
original values, but the values of the control that are sent contains the
new values. If there's a difference, the corresponding event handlers will
be invoked."

I mean that setting EnableViewState="true" only save property changes as in
the example I gave.

ASP.NET is not not my area of expertise.

But the basic concept is that:
- first request for page stores the state in a hidden field
in the form
- when the form is resubmittet the state is restored and
then the values submittet can be compared to the old values

This is a key factor to web forms attempt to mimic
win forms.

Arne

 

[Jeff Johnson]

I just tested with one checkbox and it doesn't work at all as I had
expected.
1. I set EnableViewState="false"
2. The status of the checkbox from the beginning is checked
3. I created an event handler for the checkbox with name
CheckBox1_CheckedChanged
4. I uncheck the checkbox in the browser when the website is running
5.I clicked the EmptyPostback button and when I did that the Page_Load is
called first and then is the CheckBox1_CheckedChanged called.
This was very surprising for me.The ViewState is not saved because I had
set ViewState="false" so how is it possible that
the CheckBox1_CheckedChanged is called. So my understanding from your mail
is that the CheckBox1_CheckedChanged should not be called when I have
disabled the ViewState as I had done.

Can somebody explain this ?

Let me try to phrase this as I understand it. Tell me if I'm wrong about any
of my assumptions:

1. In your .ASPX page you have declared a <CheckBox> object and set the
Checked property to true.

2. You load the page and the box is checked. You uncheck it and post back.

3. Your CheckChanged handler fires.

This all sounds fine, and here's why: the source of the .ASPX page is
examined and ASP.NET says "this check box should be checked," because you
have explicitly set the Checked property. However, the POST data coming back
says

checkBox1.Checked = false

so ASP.NET knows that a change has occurred and it fires the event. The
check box might also be unchecked when the form is rendered back to the
browser, because of the beforementioned POST data coming back and stating
that the box is unchecked. Now here's where you will see view state in
action (I think): hit the Empty Postback button AGAIN. The POST data will
probably include the

checkBox1.Checked = false

again, but since there's no "previous state" to compare it to (since
ViewState is disabled), ASP.NET will look at the default state of the check
box (Checked = true) and assume it has changed yet again, which means it
will raise the CheckChanged event AGAIN event though nothing really changed.

I'm not positive that this is what will happen, but give it a try.

 

[Tony Johansson]

Let me try to phrase this as I understand it. Tell me if I'm wrong about
any of my assumptions:

1. In your .ASPX page you have declared a <CheckBox> object and set the
Checked property to true.

2. You load the page and the box is checked. You uncheck it and post back.

3. Your CheckChanged handler fires.

This all sounds fine, and here's why: the source of the .ASPX page is
examined and ASP.NET says "this check box should be checked," because you
have explicitly set the Checked property. However, the POST data coming
back says

checkBox1.Checked = false

so ASP.NET knows that a change has occurred and it fires the event. The
check box might also be unchecked when the form is rendered back to the
browser, because of the beforementioned POST data coming back and stating
that the box is unchecked. Now here's where you will see view state in
action (I think): hit the Empty Postback button AGAIN. The POST data will
probably include the

checkBox1.Checked = false

again, but since there's no "previous state" to compare it to (since
ViewState is disabled), ASP.NET will look at the default state of the
check box (Checked = true) and assume it has changed yet again, which
means it will raise the CheckChanged event AGAIN event though nothing
really changed.

I'm not positive that this is what will happen, but give it a try.

Yes this was exactly what happen and what I wrote.

//Tony

 

[Jeff Johnson]

Yes this was exactly what happen and what I wrote.

Okay. Does this experience help you understand what ViewState is for and
what can happen if you disable it or are you still confused?

 

[Tony Johansson]

Okay. Does this experience help you understand what ViewState is for and
what can happen if you disable it or are you still confused?

Now I understand how ViewState work with TextBox, Label and CheckBox but
can you explain how it works with ListBox.

I did a little experiment with a ListBox. I have this eventhandler for the
ListBox that is fired when an item is selected.
protected void ListBox1_SelectedIndexChanged(object sender, EventArgs e)
{
string myValue = ListBox1.SelectedValue;
}

First I use the default which is the same as EnableViewState="true" and when
I select an item and then click on the EmptyPostback button a Postback is
sent and the event handler is called ListBox1_SelectedIndexChanged and
the selected value is assigned to myValue so all this works as expected.

Now I set EnableViewState="false" and run throught the same procedure and
it works just as good as it does when I have
set EnableViewState="true".
So as a summary when I have a ListBox it seems to me that the result is the
same no matter if the EnableViewState="false" or
EnableViewState="true".

Can somebody explain that ?

//Tony

 

[Jeff Johnson]

Now I understand how ViewState work with TextBox, Label and CheckBox but
can you explain how it works with ListBox.

I did a little experiment with a ListBox. I have this eventhandler for the
ListBox that is fired when an item is selected.
protected void ListBox1_SelectedIndexChanged(object sender, EventArgs e)
{
string myValue = ListBox1.SelectedValue;
}

First I use the default which is the same as EnableViewState="true" and
when I select an item and then click on the EmptyPostback button a
Postback is sent and the event handler is called
ListBox1_SelectedIndexChanged and
the selected value is assigned to myValue so all this works as expected.

Now I set EnableViewState="false" and run throught the same procedure and
it works just as good as it does when I have
set EnableViewState="true".
So as a summary when I have a ListBox it seems to me that the result is
the same no matter if the EnableViewState="false" or
EnableViewState="true".

Can somebody explain that ?

There's no difference between that and the check box, assuming there is no
item in the list box that is marked as the currently-selected item in the
..ASPX page itself (and I don't even know if that's possible to do). Think of
it this way: the page declares the list box and its items, and the current
selection is -1 (nothing selected). So whenever you select an item you will
have a SelectedIndex that is NOT -1 and therefore SelectedIndexChanged will
be fired.

ViewState manifests its usefulness when you make MULTIPLE postbacks. You're
just testing an initial page load followed by a single postback.

Here's a second thing to do: After you've posted back to one of your pages
with ViewState off, hit Refresh. The page will probably revert to its
default state. If ViewState were on, it should retain the changes you made
to it.

Another feature of ViewState is its ability to store arbitrary data that
you'd otherwise have to use hidden INPUT fields for.

 

[Tony Johansson]

There's no difference between that and the check box, assuming there is no
item in the list box that is marked as the currently-selected item in the
.ASPX page itself (and I don't even know if that's possible to do). Think
of it this way: the page declares the list box and its items, and the
current selection is -1 (nothing selected). So whenever you select an item
you will have a SelectedIndex that is NOT -1 and therefore
SelectedIndexChanged will be fired.

ViewState manifests its usefulness when you make MULTIPLE postbacks.
You're just testing an initial page load followed by a single postback.

Here's a second thing to do: After you've posted back to one of your pages
with ViewState off, hit Refresh. The page will probably revert to its
default state. If ViewState were on, it should retain the changes you made
to it.

Another feature of ViewState is its ability to store arbitrary data that
you'd otherwise have to use hidden INPUT fields for.

When I switched Off ViewState and do many postback I can see that
SelectedIndexChanged will
be fired.for each postback even when I don't select a new item.

So I would say that I understand quite a bit of how ViewState works now.

Many thanks Jeff

//Tony