by John Mark Osborne, <jmo@best.com>, http://www.best.com/~jmo
Back Button
Navigation that Knows Where You've Been
BONUS: BACKBTN.FP3
PLATFORM: Mac/Win
One of the most common navigation experiences that the majority of computer users share is the Web browser. For many, the easy access and hype over the Web is bringing new users faster than the computer gaming market ever did. This is an important consideration when designing an interface for your FileMaker databases. If an interface looks and acts in a fashion familiar to the user's experience, then it will be easier to use and less intimidating.
How It Works
The basic idea is simple, just store in a field where you are before you leave. In a general browsing scenario, there are two common movements: changing records and changing layouts. If the movement through the database is handled by scripts rather than the FileMaker interface navigation elements, we can record our present position in terms of layout location and record location. This way, we'll be able to refer to the visited path information in order to navigate back through it by hitting the back button.
Logging the Movement
Whenever you change layouts or go to a different record, the "Log Movement" script is run.
Set Field ["Forward",""""]
Set Field ["Back", "Case(IsEmpty(Back), Serial & " " & Status(CurrentLayoutNumber), Back & "¶" & Serial & " " & Status(CurrentLayoutNumber))"]
The first Set Field initializes the Forward Field. The reason for this is that the forward tracking needs to restart if you continue forward after backing through your previous movements. The second Set Field records the location you're leaving. The case statement checks to see if there are already values in the Back field. If there isn't, the location can simply be set but if there is then a return needs to precede the next location so that it is listed below the previous value(s).
The only time the Forward field is written to is if you hit the Back button. Basically, if you backtrack your location with the Back button, the Back field contents is moved over to the Forward field so that you can hit the Forward button and continue in the direction you just backed through.
The serial field is an auto enter serial number field that provides the unique value to identify which record you're on. The layouts are referenced by number evaluated by "Status(CuerrentLayout)". Layouts are numbered from top to bottom as they appear in the "Set Layout Order" dialog.
Custom File Type
What is being written to the Back or Forward fields is a custom file type not unlike a tab separated text file. The convention in the bonus file is to list the record's serial number followed by a space and then the layout number. Each location instruction is separated by a return character.
The Back Button Script
The Back button script first looks to see if there is any destination recorded in the Back field.
If ["IsEmpty(Back)"]
Else
If there isn't a destination, then we're at our starting point and there is nowhere to go back to. Next, we record where we have been in the Forward field so we can return later with the Forward button.
Set Field ["Forward", "Case(IsEmpty(Forward), Serial & " " & Status(CurrentLayoutNumber), Forward & "¶" & Serial & " " & Status(CurrentLayoutNumber))" ]
Again, we're making sure to honor our custom file type by determining if we need to insert a return character before the location string. Next, we make the movement:
Go To Related Record ["BACK"]
Go To Layout ["Back Layout"]
This gets us to the correct location. The Go To Related record script step is utilizing one of two self-join relationships that relate to the serial number field tracking the records. Finally, we need to remove the last location from the Back field.
Set Field ["Back", "LeftWords(Back, PatternCount(Back, "¶") * 2)"]
This sets that Back Field to the remaining stored location based on the number of existing returns evaluated by the pattern count function.
Smart Back and Forward Buttons
The dynamic Back and Forward button images put the final polish on this solution. The actual buttons are calculation fields with a container result. By evaluating whether or not there is a destination code in the Back or Forward fields, the calculations result in one of four repetitions of a global container field that stores the images representing the button status.
Conclusion
While there will be only specific situations where this kind of functionality is practical, the lesson learned in the technique of developing and executing a simple file format is great. I am going to build this system into my copy of the CDML Reference because I am tired of having to visually scan the tag list just to return to the page I left moments ago.
## END ##