hi all, i'm pretty sure that someone must have done this before:

i have a db that has 10 layouts, if a user is in layout #1 and move to #3, #4, #9, can anyone think of a way to make sure that if the user hit 'go back' button, he will be put back in #4, #3 & #1 consecutively but not #8 and #7 and #6......

in other words, it should be working just like the 'back' button in a web browser...

it would be so useful for the navigation purpose, cheers...

You need to implement a stack with a global text field. When you navigate to a new layout, execute this script:

Set Field [gNavStack , Status(CurrentLayoutNumber) & "

hmmmm

I guess you'd have an invisible global field for every layout called "layoutEntry" which keeps track of how a user arrived at the layout.

Note that this would require users to switch layouts through a script (eg: buttons -- not the layouts menu).

Lets say the use is going from any layout to layout 3:

Set field Layout3Entry, Status(currentLayoutNumber) ---because you're going from 1 to 3

Go to layout 3

You would either have to have a separate back button script for each layout or perform a case check of current layout...

Your back button for Layout 3 would be

Go to layout (layout number from field - Layout3Entry)

This scenerio would work if you go say: 1, 2, 5, 7, 4, 9

The back button would go through 9, 4, 7, 5, 2, 1

...But it would not work for 1, 4, 6, 4, 2

In this case it would go 2, 4, 6, 4, 6, 4, 6, 4, etc. and never to 1

I hadn't seen Bob's post when I posted mine... his way is much better.

that's it Bob, youve done it again thanks to Jason for your solution too

Hmmm... my post was there... then it was gone... trying again...

Bob, do you have a variation of that which will work across multiple files?

Across multiple files you can still use the basic stack idea, but you have to push the file name onto it as well as the layout number. You would need to have the global located in one file, but accessible to all files by a constant relationship. This shouldn't be difficult, but it definitely adds a bit of complexity to the basic idea.

It opens up a can of worms though. When you hit the back button, you want to restore the display to what was there before. What if the user has performed a find or sort somewhere along the way? You may have to consider stacking all the find and sort requests too. Finds can be saved by doing a 'Copy all records' and pasting into a global. Then, return to the find with a 'go to related record [show only related]. As for saving sorts, you could have a standard set of sorts that you refer to by number. Just a few things that you should think about

I tend to agree with a comment that LiveOak made quite a while ago. You really have to decide whether the Back Button navigation idea from web browsers is really suitable for a database application. It has its place but....

I've only used the Back button in applications where I have a multi-level related database so that as the user traverses up or down the tree, it keeps track and allows backtracking. It works well in that situation. However it's easy in that case since there is only one record viewed at a time. Hmm, maybe I should post that in the samples forum. It has a neat feature that creates organization/family tree type charts.

I'm using different approach: No extra fields required, only use of pause and resume

Here's an very basic but extremly powerfulexample.

To start using it launch file1.fp5.

To see the impelmentation hit exit buton on layout 1 of file1.fp5.

Enjoy

Dj

Navigator.zip

I've just added Freeze Window step and changed colours of background

Dj

Navigator.zip