Back and Forward Page

  • Thread starter Thread starter ruca
  • Start date Start date
R

ruca

Do you know how can I disable the Back and Forward commands in browser?

I want to disable that commands for some pages and others not.

How can I do that?
 
you haven't said why you need to so I'm only guessing that you have items in
the page_load that you dont want to execute. Move them into postback checks,
if that's not it you'll have to explain WHY you need to block the navigation

--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com
 
The only way is to hide them, via JavaScript, which requires opening a new
window, on the client side. Beyond that, you have to code in checks. Expire
pages works rather nicely (although it is more like a slap in the face). You
can also add if(!Page.IsPostBack) in your code so the Page_Load does not run
again. You can also work with multi-panel forms, so the nav back will still
use the same ViewState (not effective in all cases).

Since I have no clue what your app does, all I can offer is very generic
suggestions.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
 
Ok.
I login into a page that give me options contents (menu options) to
navigate. When I do exit, I'll go to the login page again, right?
What I want is when I click on Back button (after do Exit) do not permit
viewing pages in th history back.
Hope you can understand.
 
Using document.location.replace in JavaScript shouldn't keep the page in the
history ("skipping" over it when using the back/forward buttons).
Most often you want to "suppress" the back button because of another
problem. You may want to solve the original problem instead...

Patrice
 
So let's say you have the following situation:

1. You have a page that allows you to see the 1-many addresses associated
with a single person.
2. There is an Add, Edit and Delete button to add, edit and delete addresses
for the current person.
3. Each button goes to another screen: the add takes you to a new screen to
"add" records. The edit takes you to a similar looking screen, but with all
the data filled in so you can edit. The delete page highlights the record
you're about to delete and asks to confirm the delete with a yes or a no.
4. In the case of the Add and the Delete, if you allow a user to click a
BACK button after doing either of these, there is potential for getting
confused. On the delete screen it will show the old record that you already
deleted. On the add screen, you potentially could add the same record AGAIN
thereby creating a primary key violation. While this is the user's fault,
and we could provide a user friendly error message suggesting that they've
already added this record, they're still confused, and we don't want to get
a call from this confused user.

Without removing the BACK button by removing the toolbar, is this
document.location.replace the way to go? Without a toolbar, of course a
person can still go back if they want to badly enough, but if they're that
smart, they probably know better.

Comments? Thanks.

Mark
 
For the edit page. The user could just by mistake enter the same data
another day (possibly from a paper source ?) and he will have the same
error. This is not specific to the use of the "back" button. The page should
handle the possible primary key violation (that will solve the problem
however it happens).

For the delete page, once a neophyt user is more experienced, or another one
that is already, could be surprised not to be able to see again the deleted
address as he might expect when using the back button. For this one my
personal preference would be still to preserve the "usual" behavior of the
back button (to see past pages).

You can't hide this button. You can prevent a page from being added to the
history (using document.location.replace for navigation). But I wonder now
if you would'nt have still a problem when you post data - as you see I'm not
used to "hide" these buttons ;-)...

A last option I didn't thought at first would be to avoid caching the page.
This way when using back the page would be reloaded and refreshed with the
up to date data ?

Good luck.

Patrice

--
 
Without removing the BACK button by removing the toolbar, is this
document.location.replace the way to go? Without a toolbar, of course a
person can still go back if they want to badly enough, but if they're that
smart, they probably know better.

Want to badly enough? You mean if they know to navigate with the
Alt-arrow keys? I don't think I'd count on that! :-)

Somebody earlier in the thread stated it: It is not possible to
disable backward and forward navigation.

I code pages like that as a state machine so that all three (four?)
pages are the same page and I pass back and forth state and event
tokens so that I know where I am. That way if they update the record
and then navigate back to the "update" page, instead of viewing the
same record they're back to the list of records.

It makes it darned hard to bookmark pages, though.

-- Rick
 
How do you do that?

Ruca

Guinness Mann said:
Want to badly enough? You mean if they know to navigate with the
Alt-arrow keys? I don't think I'd count on that! :-)

Somebody earlier in the thread stated it: It is not possible to
disable backward and forward navigation.

I code pages like that as a state machine so that all three (four?)
pages are the same page and I pass back and forth state and event
tokens so that I know where I am. That way if they update the record
and then navigate back to the "update" page, instead of viewing the
same record they're back to the list of records.

It makes it darned hard to bookmark pages, though.

-- Rick
 
I said:
I code pages like that as a state machine so that all three (four?)
pages are the same page and I pass back and forth state and event
tokens so that I know where I am. That way if they update the record
and then navigate back to the "update" page, instead of viewing the
same record they're back to the list of records.

How do you do that?

Well, I'll show you an example in a second, but first I want to mention
that it's not just the back-button you've got to worry about; there is
also the refresh button, to say nothing of Ctrl-Refresh.

For a good treatment of the whole topic I recommend:

Trap the Browser Refresh by Dino Esposito
"Learn to catch and handle the Refresh trigger so it works the way
you want it to."

From the September 2003 issue of asp.NetPro magazine.

It is available here:
http://www.aspnetpro.com/features/2003/09/asp200309de_f/asp200309de_f.asp

That has no relation to what I'm about to show you, but Mr Esposito's
solution is probably a lot better than mine. I just do mine this way
because I'm an old state machine guy.

Now, going back to the proposed Customers Addresses example, I'm going
to write some simple ASP style code, and it's only going to be
schematic, but I think you will get the idea.

----
Dim myName

myName = Request.ServerVariables("SCRIPT_NAME")


Dim myEvent, myState

If session("state") = "" Then
myState = "ListingAddrs"
session("state") = myState
Else
myState = session("state")
End If

' Events
' AddAddr - User wants to add an address
' DeleteAddr - User has requested a delete
' EditAddr - User wants to modify an address
' InsertAddr - User has requested we save the new address
' UpdateAddr - User wants us to update the edited address
' Cancel - User wants to back out of the current state
' Default - Initialization or an unknown event

' States
' AddingAddr - Displaying blank form for new address
' DeletingAddr - Verifying & performing delete decision
' EditingAddr - Displaying addr update form
' ListingAddrs - Table style display of addresses

----
Now for the meat.

----
myEvent = request("event")

select case myEvent

case "EditAddr"
Call displayEditAddrForm(params)
myState = "EditingAddr"

case "AddAddr"
Call displayAddAddrForm()
myState = "AddingAddr"

case "InsertAddr"
Call insertAddrRecord(params)
Call listAddrs()
myState = "ListingAddrs"

case "DeleteAddr"
Select Case myState
case "EditingAddr"
Call deleteAddrVerify()
myState = "DeletingAddr"

case "DeletingAddr"
Call deleteAddr(params)
Call listAddrs()
myState = "ListingAddrs"
End Select

case "UpdateAddr"
Call updateAddrRecord(params)
Call listAddrs()
myState = "ListingAddrs"

Case "Cancel"
If myState = "ListingAddrs" Then
Response.Redirect("homepage.asp")
Else
Call listAddrs()
myState = "ListingAddrs"
End If

Case Else
Call listAddrs()
myState = "ListingAddrs"

End Select

session("state") = myState

----
Now that's pretty much the whole program. I'll show an example
subroutine call to one of the display forms so that you can see the
linkage through the state and event variables.

----
<%
Sub displayAddAddrForm()

Call displayHtmlHead("Adding Address")
%>

<form action="<%=myName%>" method="get" id="form1" name="form1">

<input type="hidden" name="event" value="">

....HTML to display the form and accept the parameters...

<input type="button" id="button1" name="button1" value="AddAddr"
onclick='form1.event.value="InsertAddr";form1.submit();'>

<input type="button" id="button1" name="button1" value="Cancel"
onclick='form1.event.value="Cancel";form1.submit();'>

</form>

<%
Call displayHtmlTail()
End Sub
%>

----
The other subs either are the same thing, or are simply database access
routines to save the data. Personally, I usually put each sub in it's
own include file for reuse, but you could just tack them all on after
the main page code.

Study this and then if you have questions, ask away.j

-- Rick
 
Back
Top