Dealing with the Back button

I

IPGrunt

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)

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
 
M

MattC

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
 
T

Tom wilson

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.
 
I

IPGrunt

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.


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
 
T

Tom wilson

That makes sense, and is likely. but of all the trillions of things
that could expire the page, where to look first?
 
T

Tom wilson

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...
 
G

Guest

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
 
T

Tom wilson

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
 
G

Guest

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
 
G

Guest

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,598
Members
45,158
Latest member
Vinay_Kumar Nevatia
Top