I recently tackled a request from a client to implement a back button that functioned similar in nature to the back button in a web browser. This is certainly not an uncommon request and a simple explanation as to why this isn’t practical normally results in the client withdrawing their request. However, the customer was adamant that they wanted this functionality. So, I set out to design a solution for them and came up with a solution using snapshot links.
Using snapshot links (.fmpsl), a user’s layout, found set, sort order and current record can be restored without any fuss. The trick is making this whole process as seamless as possible for the user. And a few other, minor, gotchas. The general idea behind this is simple and requires only a few aspects to be in place. I have split these up into the following categories: script triggers, snapshot history and restoring snapshots.
The first step is to create a script trigger that saves a snapshot link every time the layout changes. This snapshot link will store the user’s current layout, found set, sort order and current record in the snapshot link. The snapshot link is generated with a timestamp in the filename to keep it unique and the snapshot links are stored in the temporary path. The second step is to create a script trigger that updates the snapshot history variable (detailed below) when a new window is opened. This script will remove the most recent snapshot link path from the history variable. One thing of note: On Layout Exit script triggers will not be triggered if you navigate away from the layout while in find mode. Keep this in mind when creating navigation scripts.
At the time the snapshot link is created the full path for the snapshot link is stored in a global history variable ($$history). Every snapshot link gets added to the beginning of the history variable with a return character at the end. The result is that the history variable contains a return-delimited list of paths to snapshot links.
Here is where things get to be a little trickier and where making things seamless comes in to play. Here is a brief timeline of what occurs when a snapshot link is opened: 1. The solution is opened in a new window (at the default location and size) and the default layout is displayed. 2. The OnWindowOpen script trigger is fired. 3. The snapshot loads the layout, found set, sort order and current record. The first problem you will run into is that you haven’t actually navigated back to the desired layout and found set. You now have two open windows, one of which has a window name of the filename for the snapshot link. This new window is not ideal. I was able to resolve this with the following: Store the current window name, location and dimensions in global variables before opening the snapshot link and rename the current window. Restore the window to the location and dimensions we stored once the snapshot link is opened. This can be accomplished by the OnWindowOpen script trigger. NOTE: You cannot do this step in the same script that opens the snapshot link. You will need a separate script that is triggered and ran by the window opened with the snapshot link. Rename the new window then close the old window. But don’t create a snapshot for this window! See other notes below. This results in the user seeing a brief flash on the screen followed by their previous layout and found set now being restored. Nearly seamless!
The solution I built this feature for had some dialog windows at various points. I did not want to include these dialog windows in the history so I incorporated a bypass global variable. Any script that opened a dialog window would set the bypass variable to 1. I then incorporated an if statement at the beginning of my scripts that set bypass to “” and exited the script when bypass was set to 1. This effectively routes around the creation of the snapshot link, where desired. This was also useful when I realized that closing the old window caused a new snapshot link to be created. This technique is not the most robust method out of the box but it could certainly be expanded upon. One idea I had was to encode additional parameters into the snapshot link name. These parameters could identify active layout objects, local variables, window parameters, etc. This was not necessary for this particular implementation but could be added into future implementations.
I have put together a simple demonstration file detailing the methods I described above. Click here to download the demo file.
Calvin Cooper is a FileMaker Certified Developer at Skeleton Key.
About Skeleton Key
Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.