I hear you. We've tried a number of different trigger based things and if you just want to capture layouts, they can work. We use an OnLayoutExit script in SeedCode Complete, for example, to do simple back and fwd stuff. BackMagic adds the ability to use "back" to get to tabs within a layout (so if you click from one tab to another, then click "back", you go back one tab, not one layout). But that is actually kind of annoying, so we use the triggers for most things now.
To roll your own, you can use nearly the same scripts from BackMagic, just write the $$sc_Back and $$sc_FWD stacks using OnLayoutExit script triggers instead of using BackMagic's fields.
1 of 1 people found this helpful
If I were putting this together, I'd be trying to build something with as few components to transfer as easily as possible between different layouts and files. So I'd avoid script triggers for logging navigation history as much as possible — you can't simply copy/paste script triggers between layouts, and I may want to use OnLayoutEnter and OnLayoutExit triggers for other things in different layouts.
One thing you can simply copy/paste between layouts and files is button objects. Buttons can have conditional formatting applied to them, which means you can run a calculation every time the screen refreshes — such as when loading a new layout. Using the Let() function, that calculation can set global variables that can store the navigation history. You'll find some discussion of using conditional formatting and Let() this way here. The buttons can then be simple "Go to Layout[name by calculation]" buttons with no script, with the layout name calculation based on the global variables.
The calculation will have to be somewhat sophisticated — you'll want to make sure that repeat refreshes on one layout don't duplicate that layout in the last position of the navigation history, for example. If you have FileMaker Pro Advanced, I advise using custom functions for those calculations so that, when the time comes to change how it works, you'll only have one place to make changes rather than having to edit conditional formatting calculations on every layout. Custom functions are one more thing to transfer between files, but custom functions are easy to import.
I haven't tested any of this for the particular purpose of back and forward navigation buttons, but that's where I'd start.
Hey John, this is where I was headed, but the thing that stumped me is how to replace the traditional "listening fields" with a script step.
Trapping the Back and Fwd buttons in the stack are easy enough, but how to add to the stacks when I jump to any 'random' layout, I am unsure on how the stack gets manged by an exit layout script trigger, rather that the 'listening field'.
I had some time today, and this problem was nagging at my brain, so I came up with a demo of the approach I suggested. Look, Ma! No scripts!
One caveat is that the solution, as implemented, is not multi-window friendly; but adapting it to a multi-window application is straightforward.
BackButton.fp7.zip 7.5 K
Hey JB, this is truly amazing!
No scripts, no script trigggers, no special fields - very very cool.
ok, so if I keep the custom functions "as is", can I please steal it?
Feel free to use it. I'm personally not a big fan of browser-style back and forward buttons in FileMaker applications; so if you don't get any use out of it, my effort may be for naught.
... better than cluttering your scripts with variables. I have a simple script which virtually does the same thing passing parsed variables but it only stacks so high... It does, however allow me to go to objects/tabs or layouts
I had a little trouble trying to get it working when I first opened the file... doh!... as of course there was no history yet.. but once I manually changed layouts it tracked my movements well.
Very nice. Exactly what I've come to expect from you Jeremy.
JB, I have fitted it to a solution I have currently and it's behaving really weird!
What I happened to notice is that the NavBackLayoutName appears in the dataview and the tootltip as if it's ready to go BACK to that layout, until I the moment I click on the back button, then the value for the NavBackLayoutName dissapears! Very ODD!
What is even more bizzarre, I have tried it in a new test solution (no scripts at all) and that works fine.
Yes, I have some scripts that run when leaving and entering all layouts, but these do not affect the variable, that's for sure.
In the data viewer, are you looking at the variables, or at the functions? You're best off not using the custom functions in the data viewer. Every time the NavBackLayoutName evaluates, it will modify the variables as if you're using the "back" button to change layouts. It's the difference between looking where you're about to leap, and actually leaping.
Both of the variables used by the functions include the current layout at the top of the list by design. This is so the NavLogCurrentLayout function can know where you've been, even if you don't get there using the back or forward buttons.
I've tried looking at both the custom function value and the variable. They both show correctly what the previous layout name is, but alas, the second I click on the back button, the values dissappear and I get error 105.
Very odd indeed.
I just don't understand how the variable gets blown away. There must be a timing issue between when the variable gets set and when the goto layout step is invoked.
I just can't work out where or why it's happening.
I will be experimenting with it some more... I am only guessing that there is some objects on the layout that could be throwing the timing of the custom function out??
here's an interesting excercise, take a copy of your sample backbutton file, then delete all the custom functions.
Import them again from the original backbutton file and watch it break!!
ummm, I don't know how to explain why, because the custom functions look fairly transportable!
It looks like I will have to copy and paste each individual calculation used in each cutom function.
Is this right or am I going insane(r)
Interesting, I have managed to work around the problem and YES, it does seem to be a timing issue!
Very odd, but if I replace the gotolayout button with a script, then use a variable to capture the NavBackLayout, use that variable for the gotolayout script step, then it works fine. If the script simply grabs the custom function for the goto layout, it breaks! Looks like the custom function needs to have the variable to 'trigger' the custom function calculation? Is this why you used variables on the layout of your demo?
ok, I'm wrong again, this needs more investigation, because this seems to not be consistent... stay tuned.