Dealing with the Back button

  • Thread starter Thread starter Tom wilson
  • Start date Start date
As far as I know I do, there's a submit button (with no codeback code)
that is clicked to cause a postback. If the page lives in the
browser, why would the form data be cleared when the back button is
clicked ? (after the submit button is clicked)
Click to expand...

In my initial post to you, I thought you had not submitted the page. I
wanted to be sure that you understood the process.

By the way, why is there no code behind the submit button?

So, here we have two cases:

If the page, form and controls are set to use viewstate, then after
postback, those values will persist.

If the page is not submitted, ie, no postback, there's not gonna be any
viewstate created.

These are the two states to consider BEFORE the back button gets
clicked.

You can test, to see which state you're in--use the debugger to examine
viewstate. There are other techniques...this is a digression, but I
read a nice article recently that described how viewstate is encoded. I
can't recall the URL now, but if you search I'll bet you find it. This
way you could even write some of those values out to screen or a file
to convince yourself they are there.

If you have viewstate, then when you go back, and return, I wonder if
your controls are being reinitialized. This is what Juan was referring
to.

Again, use the debugger and write some test code.


-- ipgrunt
 
Ok, if you have expired the page then clicking the back button will cause
the browser to ask for the page, from scratch, as the content of the page
expired so did the viewstate stored in the page. AS there is no viewstate
your controls are empty.

It would seem that the page is expiring so the browser is asking for a new
version of the page.

MattC
 
Debugger? I can never get that to work. I assume because I need to
install VS.Net on the server. Is it wise to install VS.Net on a live
production server? The thought makes me a bit nervous.
 
Debugger? I can never get that to work. I assume because I need to
install VS.Net on the server. Is it wise to install VS.Net on a live
production server? The thought makes me a bit nervous.
Click to expand...


Man, using the debugger is half of what .NET is all about in
increasing programmer productivity. If you're not using the debugger,
you're flailing in the dark (which you are).

Can't you load the framework on your workstation?

Theoretically you shouldn't debug on a live server, but you CAN make
a development site there that users won't see and work that way. Make
sure you're NOT using the server side debugger, as you can stop the
entire IIS processing (or maybe not with ASP.NET... I really haven't
tried).

I gotta go to work. Do yourself a favor and get a debugging setup
working. You'll save loads of time.

-- ipgrunt
 
That makes sense, and is likely. but of all the trillions of things
that could expire the page, where to look first?
 
I've done a test using a time field. The page, when using the Back
button, is retrieved from IE's cache. It's not a fresh copy of the
page from the server. The latter would explain everything.

So the server marked the page as expired? Where ? How? How to stop
it?

Thanks...
 
Did you check the Internet Explorer -> Tools -> Internet Options -> Temporary
Internet Files -> Settings?

I have no problems with a standard .ASPX pages with Webcontrols (RadioButton
Group, TextBox etc.) and the browser Backbutton. When I use normal
HTML-controls then the fields are empty.

EXAMPLE:
<%@ Page language="c#" Codebehind="project.aspx.cs" AutoEventWireup="false"
Inherits="project.project" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>project</title>
<meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema"
content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body MS_POSITIONING="GridLayout">
<form id="Form1" method="post" runat="server">
<asp:TextBox id="TextBox1" style="Z-INDEX: 101; LEFT: 16px; POSITION:
absolute; TOP: 24px" runat="server"></asp:TextBox>
<asp:TextBox id="TextBox2" style="Z-INDEX: 102; LEFT: 16px; POSITION:
absolute; TOP: 56px" runat="server"></asp:TextBox>
<asp:Button id="Button1" style="Z-INDEX: 103; LEFT: 16px; POSITION:
absolute; TOP: 88px" runat="server"
Text="Button"></asp:Button><INPUT style="Z-INDEX: 104; LEFT: 24px;
POSITION: absolute; TOP: 144px" type="text"><INPUT style="Z-INDEX: 105; LEFT:
24px; POSITION: absolute; TOP: 176px" type="text"><INPUT style="Z-INDEX: 106;
LEFT: 24px; POSITION: absolute; TOP: 208px" type="submit" value="Submit">
<asp:RadioButtonList id="RadioButtonList1" style="Z-INDEX: 107; LEFT:
240px; POSITION: absolute; TOP: 24px"
runat="server" Width="112px">
<asp:ListItem Value="Item 1">Item 1</asp:ListItem>
<asp:ListItem Value="Item 2">Item 2</asp:ListItem>
</asp:RadioButtonList>
</form>
</body>
</HTML>


Alexander Meeder
 
Yes, it works for me too. I don't get it cause my pages don't work
with IE. Firefox and Netscape retain the values fine.

Thanks!


On Thu, 17 Feb 2005 04:59:02 -0800, "Alexander Meeder" <Alexander
 
Correct me if I'm wrong, but it sounds like, once you submit your page to the
server, your server app is returning some type of error page, requiring you
to go "back" to the form page to fix your errors. Have you tried simply
having the server bring the user right back to the form page, with some error
text up top, and all the field data maintained? Since you've posted it to the
server, the server has all your dymamic fields + all the field data entered,
so it can just regenerate the form page, with submitted values populated.

In this scenario, there's no need to push the Back button.

David Makogon
 
Here's what's happening (AFAIK):
When you click the submit button, it sounds like you are going to a new page
that tells the user that something went wrong...or am I not reading this
correctly? What you should be doing is keeping the user on the same page as
your dynamically created form and on submission of that form (postback), set
up some error strings and whatnot on the page to let the user know what they
need to correct. Now send the form page back to the user. This way you still
have your ViewState active and it will keep your form values populated. Well,
as long as you don't reset them on postback.

What you're seeing when you go to a new page and then hit the back button,
is the page that was saved in your browser's history. This page is a copy of
what that page looked like when it was last sent from the server. You're
seeing empty fields because that's what that page looked like when it was
last sent to the client from the server. Any interaction that the user did to
that form page will ultimately be lost because that was all done client side
and doesn't affect the copy in the browser's history. Now, if you posted back
that form page with error strings or something of the like, then after the
user fixed the errors and submitted the form again, and on the subsequent
page(a new different confirmation page maybe) the user would click the
browser's back button, they should see a copy of the form with the fields
filled in and the error strings still present. Exactly what was last sent
from the server to the client. If they clicked the back button again, they
would see the empty form page.

Now don't take this as 100% correct as it is late on a Friday afternoon, but
I hope this gives you some better direction.
 
Back
Top