Simple page won't maintain state

[Tom wilson]

I have created a very simple example that doesn't work. Form1
contains a textbox and a button:

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e
As System.EventArg s) Handles Button1.Click
Response.Redire ct("login.aspx" )
End Sub

Very simple. Forget what login.aspx does, it's just somewhere to
redirect to.

So, I load this page, enter text and click the button. It takes me to
login.aspx. Fine.

Hit the back button and the textbox is empty. Why is the textbox
empty? Aren't .aspx pages supposed to maintain their state?

Both the textbox and the form have their viewstate properties set to
true.

Thanks!

[Karl Seguin]

Tom:
They maintain their state through server-side round trips. That is, when
you click a linkbutton or a button the page will postback to itself and
state will be preserved. In your case, when you click Button1 the page
posts back to itself, and if you were to check the textbox text property,
you would see the value is maintained. When you Redirect you are going to
another page, at this point your persistante state is lost...the viewstate
is no longer kept. When you click back, you are going back to the original
page, state isn't maintained (it's already been thrown away)...it's like ur
visiting it for the first time. In other words, viewstate persists data
whilst doing roundtrips to the same page. The minute you Response.Redire ct,
the viewstate is lost. hitting back is like requesting Form1 for the very
first time.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Tom wilson" <ye*******@nosp am.com> wrote in message
news:55******** *************** *********@4ax.c om...

I have created a very simple example that doesn't work. Form1
contains a textbox and a button:

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e
As System.EventArg s) Handles Button1.Click
Response.Redire ct("login.aspx" )
End Sub

Very simple. Forget what login.aspx does, it's just somewhere to
redirect to.

So, I load this page, enter text and click the button. It takes me to
login.aspx. Fine.

Hit the back button and the textbox is empty. Why is the textbox
empty? Aren't .aspx pages supposed to maintain their state?

Both the textbox and the form have their viewstate properties set to
true.

Thanks!

[Karl Seguin]

Tom:
They maintain their state through server-side round trips. That is, when
you click a linkbutton or a button the page will postback to itself and
state will be preserved. In your case, when you click Button1 the page
posts back to itself, and if you were to check the textbox text property,
you would see the value is maintained. When you Redirect you are going to
another page, at this point your persistante state is lost...the viewstate
is no longer kept. When you click back, you are going back to the original
page, state isn't maintained (it's already been thrown away)...it's like ur
visiting it for the first time. In other words, viewstate persists data
whilst doing roundtrips to the same page. The minute you Response.Redire ct,
the viewstate is lost. hitting back is like requesting Form1 for the very
first time.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Tom wilson" <ye*******@nosp am.com> wrote in message
news:55******** *************** *********@4ax.c om...

I have created a very simple example that doesn't work. Form1
contains a textbox and a button:

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e
As System.EventArg s) Handles Button1.Click
Response.Redire ct("login.aspx" )
End Sub

Very simple. Forget what login.aspx does, it's just somewhere to
redirect to.

So, I load this page, enter text and click the button. It takes me to
login.aspx. Fine.

Hit the back button and the textbox is empty. Why is the textbox
empty? Aren't .aspx pages supposed to maintain their state?

Both the textbox and the form have their viewstate properties set to
true.

Thanks!

[Tom wilson]

Ok, I understand that.

Lets start over, that was an inaccurate example.

This is a survey page that works like so:

- User gets page, fills out, submits
- Submit codeback sees entry errors and inserts error messages as
LiteralControls into the Placeholder sequence.
- The user gets the page back with the errors inline. All is ok.

At this point there are 2 choices:

1 - The user corrects the error and re-submits. That works.
or
2 - The user hits the back button to correct the error. In this case,
after clicking back, all the controls on the page are reset.

So there is no response.redire ct at all here. If one moves forward
(correct, submit, correct, submit) it works perfect. If the back
button is clicked, the form reverts to its previous state (error
messages still in place) but the controls are all reset.

How does one deal with maintaining state when the user hits the Back
button?

On Mon, 14 Feb 2005 15:39:43 -0500, "Karl Seguin" <karl REMOVE @
REMOVE openmymind REMOVEMETOO . ANDME net> wrote:

Tom:
They maintain their state through server-side round trips. That is, when
you click a linkbutton or a button the page will postback to itself and
state will be preserved. In your case, when you click Button1 the page
posts back to itself, and if you were to check the textbox text property,
you would see the value is maintained. When you Redirect you are going to
another page, at this point your persistante state is lost...the viewstate
is no longer kept. When you click back, you are going back to the original
page, state isn't maintained (it's already been thrown away)...it's like ur
visiting it for the first time. In other words, viewstate persists data
whilst doing roundtrips to the same page. The minute you Response.Redire ct,
the viewstate is lost. hitting back is like requesting Form1 for the very
first time.

Karl

[Tom wilson]

Ok, I understand that.

Lets start over, that was an inaccurate example.

This is a survey page that works like so:

- User gets page, fills out, submits
- Submit codeback sees entry errors and inserts error messages as
LiteralControls into the Placeholder sequence.
- The user gets the page back with the errors inline. All is ok.

At this point there are 2 choices:

1 - The user corrects the error and re-submits. That works.
or
2 - The user hits the back button to correct the error. In this case,
after clicking back, all the controls on the page are reset.

So there is no response.redire ct at all here. If one moves forward
(correct, submit, correct, submit) it works perfect. If the back
button is clicked, the form reverts to its previous state (error
messages still in place) but the controls are all reset.

How does one deal with maintaining state when the user hits the Back
button?

On Mon, 14 Feb 2005 15:39:43 -0500, "Karl Seguin" <karl REMOVE @
REMOVE openmymind REMOVEMETOO . ANDME net> wrote:

Tom:
They maintain their state through server-side round trips. That is, when
you click a linkbutton or a button the page will postback to itself and
state will be preserved. In your case, when you click Button1 the page
posts back to itself, and if you were to check the textbox text property,
you would see the value is maintained. When you Redirect you are going to
another page, at this point your persistante state is lost...the viewstate
is no longer kept. When you click back, you are going back to the original
page, state isn't maintained (it's already been thrown away)...it's like ur
visiting it for the first time. In other words, viewstate persists data
whilst doing roundtrips to the same page. The minute you Response.Redire ct,
the viewstate is lost. hitting back is like requesting Form1 for the very
first time.

Karl

[Karl Seguin]

Tom:
it seems to me that choice #1 and #2 are the same thing (or atleast that the
user would be doing them for the same purpose). Not sure why users would hit
the back button to correct if it's clear that they can simply correct it on
the page infront ofthem and hit resumit (#1).

You can do a google search for 'ASP.net back button' and get a lot of
relevant hits. Remeber:

User views page.aspx
User submits and postback to page.aspx
from this point, when the user hits "back" it's like he/she is back at step
one, viewing page.aspx for the first time.

Not much you can do about it...but in my experience users know this is how
web apps work...fill out a form, get an error message and make
correction....t hey know not to hit back when the error message is staring
them in the face... Perhaps what you should do in addition to the error
message is display a red asterix next to the field in error so that their
attention is drawn there for correction instead of to the back button...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Tom wilson" <ye*******@nosp am.com> wrote in message
news:25******** *************** *********@4ax.c om...

Ok, I understand that.

Lets start over, that was an inaccurate example.

This is a survey page that works like so:

- User gets page, fills out, submits
- Submit codeback sees entry errors and inserts error messages as
LiteralControls into the Placeholder sequence.
- The user gets the page back with the errors inline. All is ok.

At this point there are 2 choices:

1 - The user corrects the error and re-submits. That works.
or
2 - The user hits the back button to correct the error. In this case,
after clicking back, all the controls on the page are reset.

So there is no response.redire ct at all here. If one moves forward
(correct, submit, correct, submit) it works perfect. If the back
button is clicked, the form reverts to its previous state (error
messages still in place) but the controls are all reset.

How does one deal with maintaining state when the user hits the Back
button?

On Mon, 14 Feb 2005 15:39:43 -0500, "Karl Seguin" <karl REMOVE @
REMOVE openmymind REMOVEMETOO . ANDME net> wrote:

Tom:
They maintain their state through server-side round trips. That is, when
you click a linkbutton or a button the page will postback to itself and
state will be preserved. In your case, when you click Button1 the page
posts back to itself, and if you were to check the textbox text property,
you would see the value is maintained. When you Redirect you are going toanother page, at this point your persistante state is lost...the viewstateis no longer kept. When you click back, you are going back to the originalpage, state isn't maintained (it's already been thrown away)...it's like urvisiting it for the first time. In other words, viewstate persists data
whilst doing roundtrips to the same page. The minute you Response.Redire ct,the viewstate is lost. hitting back is like requesting Form1 for the very
first time.

Karl

[Tom wilson]

It seems like a rather obvious hole in the technology. You know
somebody is going to click the back button and lose pages and pages of
data. I remember another developer I knew would not write delete
confirmations into his apps. When asked 'what if someone hits delete
by accident' his reply was 'who's going to do that'? A lot of people.

This page leads me to believe this can be done:

http://www.w3schools.com/aspnet/aspnet_viewstate.asp

"When a form is submitted in classic ASP, all form values are cleared.
Suppose you have submitted a form with a lot of information and the
server comes back with an error. You will have to go back to the form
and correct the information. You click the back button, and what
happens.......A LL form values are CLEARED, and you will have to start
all over again! The site did not maintain your ViewState.

When a form is submitted in ASP .NET, the form reappears in the
browser window together with all form values. How come? This is
because ASP .NET maintains your ViewState. The ViewState indicates the
status of the page when submitted to the server. The status is defined
through a hidden field placed on each page with a <form
runat="server"> control. "

So according to this, this is a standard feature of asp.net yet I
can't get it to work. It seems a lot of people in this group ask
about disabling the back button but it's never a recommended practice.
I already do display error messages above the question in red, but
somebody's going to hit Back and freak out. They would tell me, as I
would say, 'I have yet to see an online form that says "DO NOT hit the
back button!!!!"'

I'll search around the web but I figured these being the Microsoft
newsgroups, that an answer to this would be simple and routine. Does
no one write apps capable of dealing with the back button and loss of
data?

Thanks for the replies...

On Tue, 15 Feb 2005 08:42:31 -0500, "Karl Seguin" <karl REMOVE @
REMOVE openmymind REMOVEMETOO . ANDME net> wrote:

Tom:
it seems to me that choice #1 and #2 are the same thing (or atleast that the
user would be doing them for the same purpose). Not sure why users would hit
the back button to correct if it's clear that they can simply correct it on
the page infront ofthem and hit resumit (#1).

You can do a google search for 'ASP.net back button' and get a lot of
relevant hits. Remeber:

User views page.aspx
User submits and postback to page.aspx
from this point, when the user hits "back" it's like he/she is back at step
one, viewing page.aspx for the first time.

Not much you can do about it...but in my experience users know this is how
web apps work...fill out a form, get an error message and make
correction.... they know not to hit back when the error message is staring
them in the face... Perhaps what you should do in addition to the error
message is display a red asterix next to the field in error so that their
attention is drawn there for correction instead of to the back button...

Karl

[Leo Muller]

Also in classic forms, if you hit the back button, the form fields will
still be with the data. (try!)
The viewstate gives you more options.
If in any case you want the form to be filled with the details, consider
using the session object to maitain data for each user. If you don't want
this, then add the ifpostback=fals e and reset all fields.

Leo

"Tom wilson" <ye*******@nosp am.com> wrote in message
news:rf******** *************** *********@4ax.c om...

It seems like a rather obvious hole in the technology. You know
somebody is going to click the back button and lose pages and pages of
data. I remember another developer I knew would not write delete
confirmations into his apps. When asked 'what if someone hits delete
by accident' his reply was 'who's going to do that'? A lot of people.

This page leads me to believe this can be done:

http://www.w3schools.com/aspnet/aspnet_viewstate.asp

"When a form is submitted in classic ASP, all form values are cleared.
Suppose you have submitted a form with a lot of information and the
server comes back with an error. You will have to go back to the form
and correct the information. You click the back button, and what
happens.......A LL form values are CLEARED, and you will have to start
all over again! The site did not maintain your ViewState.

When a form is submitted in ASP .NET, the form reappears in the
browser window together with all form values. How come? This is
because ASP .NET maintains your ViewState. The ViewState indicates the
status of the page when submitted to the server. The status is defined
through a hidden field placed on each page with a <form
runat="server"> control. "

So according to this, this is a standard feature of asp.net yet I
can't get it to work. It seems a lot of people in this group ask
about disabling the back button but it's never a recommended practice.
I already do display error messages above the question in red, but
somebody's going to hit Back and freak out. They would tell me, as I
would say, 'I have yet to see an online form that says "DO NOT hit the
back button!!!!"'

I'll search around the web but I figured these being the Microsoft
newsgroups, that an answer to this would be simple and routine. Does
no one write apps capable of dealing with the back button and loss of
data?

Thanks for the replies...

On Tue, 15 Feb 2005 08:42:31 -0500, "Karl Seguin" <karl REMOVE @
REMOVE openmymind REMOVEMETOO . ANDME net> wrote:

Tom:
it seems to me that choice #1 and #2 are the same thing (or atleast that
the
user would be doing them for the same purpose). Not sure why users would
hit
the back button to correct if it's clear that they can simply correct it
on
the page infront ofthem and hit resumit (#1).

You can do a google search for 'ASP.net back button' and get a lot of
relevant hits. Remeber:

User views page.aspx
User submits and postback to page.aspx
from this point, when the user hits "back" it's like he/she is back at
step
one, viewing page.aspx for the first time.

Not much you can do about it...but in my experience users know this is how
web apps work...fill out a form, get an error message and make
correction... .they know not to hit back when the error message is staring
them in the face... Perhaps what you should do in addition to the error
message is display a red asterix next to the field in error so that their
attention is drawn there for correction instead of to the back button...

Karl