Jenny wrote:
Need urgent help for an unsolved problem. In our ASP web application,
we creat a Back button and if user click on this button, it execute
history.go(-1) to go back to the previous page. All our users use IE
6.0 and most of them don't have problem with this button. But one user
reported everytime he click on this button, there is a pop-up window
shows up and ask him refresh and reload the page, after he clicks OK,
the previous page will be loaded with all the empty fields. So he will
lose all his input. I searched the google, it did mention there is
problem with Netscape for history.go(-1), but can not find any
articles for IE. And then I realized I use Response.Expires=0 to
disable the cache and force the browser to reload, but according to
the discussion from Internet, it might work for some type of browser,
might not work for other types of browsers. But we all use IE, I use
IE 6.0, he use either IE5.5 or IE 6.0, why it won't expire cache on
mine, but on his? The following is my code's snippet. Your help is
HIGHLY appreciated.
<% Response.Buffer = True %>
<% Response.Expires = 0 %>
<% Response.AddHeader "Pragma", "No-Cache" %>
<script LANGUAGE="javascript">
<!-- Back Function
function BackUp()
{history.go(-1);}
-->
</script>
In the html code,
<form method="post" action="NextPage.asp" id="form1" name="form1">
/* lots of other stuff */
<p align="center"><input type="button" Onclick="BackUp();" value="Go
to
Previous Page" name="Back"><input type="submit" value="Go to Next
Page"
name="Submit"></p>
</form>
He probably has Internet Explorer configured to always load a new copy of
the page.
Tools -> Internet Options -> General tab
Click Settings... -> "Check for newer versions of stored pages:"
His is probably set to "Every visit to the page".
Which proves once again to handle this stuff properly, instead of
"relying" on what browsers do, even in an Intranet environment.
Store the form data in a server-side session of some sort, the "Go to
Previous Page" button should then actually retrieve the ASP document
containing the form and repopulate the form using the previously stored
session values.
This still doesn't handle what happens if the user clicks "Back" on their
browser, but that can be dealt with with a redirector page between the
form and the result pages that can identify that the user has clicked
"Back".
[form (set Session.r=0)] <--
| |
v | Session.r=1?
[redirector] --------------|
|
| Session.r!=1?
v
[result (set Session.r=1)]
If that makes no sense, try using a fixed width font.
Now if the user clicks "Back" after arriving at the [result] page, the
browser reloads [redirector], not [form]. [redirector] identifies that
they were on [result] (because Session.r is now 1) and takes them to
[form], repopulating the form with data stored in the server-side session
as well. If you don't want to return to [form] when a user clicks "Back"
on [result], that's fine, [redirector] can take ANY action, like going
back to [result] with a message that the user shouldn't click "Back" or
another page entirely.
The point is, all this is handled on the SERVER, where is can be
controlled and the behaviour is always known, and does it does not "rely"
on some behaviour in a Web browser that can't even be trusted in an
Intranet environment.
--
| Grant Wagner <gw*****@agricoreunited.com>
* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
*
http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
*
http://www.mozilla.org/docs/web-deve...upgrade_2.html 
