Mysterious Button Apparitions and Log Histories
Example file: ButtonRows
Quite awhile ago, back in an example file on duplicates, I included an extra layout at the back named “Magic Portal.” It was pretty wild.
It demonstrated a useful technique: how to display buttons only when you wanted them. I first saw it used in a file by John Mark Osborne, called “Visibility.” It’s available at his website (along with other great examples): http://www.best.com/~jmo
The main difference between the technique, using an invisible portal, and one using a button which is simply calculated to not be visible, is that these buttons are not active when invisible.
Limitations of Calculated Buttons
A calculated non-visible button will still perform its script when its layout space is clicked. The field is still there; you just can’t always see it.
You can use an “If” statement to stop the script from executing if certain conditions are not met. But sometimes there are situations when, even if conditions are met, you want to be in control of when the script runs.
The invisible portal button gives you that control.
Fields Within an Invisible Portal
The trick depends on the fact that fields within a portal are only there when the relationship to that portal is valid. When the relationship is not valid, the portal is still there on the layout, but the fields within it are not only non-visible, they are not there at all. Therefore a script attached to one of these fields is not going to execute, even if you click its space within the portal.
Button Layout Technique
The button itself must be a field, however. This is solved by pasting a regular button, or any other small graphic, into a global field, of type “container.”
The script is then attached to this field, just as usual.
By the way, if you want two scripts for different buttons, you need two global fields. Repetitions won’t work in this situation.
No-Line Portal
The global field is then placed within a one-row portal. Everything must be fitted together tightly, with no lines showing and no fill. It’s kind of tricky, especially since it needs to be fairly short in order to fit into your list-view rows.
The portal itself is also set to have no line (once everything’s in it). I included instructions in the example file for all this layout stuff.
Portal Relationship: Flag to Constant
The portal needs a relationship that will be valid for any record where our conditions for visibility are met, and invalid for others. For this we’ll use a “flag” field. This is a simple calculation field that yields “1” or “” (nothing).
We will relate this field to a Constant calculation field, with a result of 1.
This way we can be assured that when our conditions are met on any record, our flag key field will be 1, and the Constant field at the other end will also be 1, on any record.
Cute Little Button
The little button will seemingly pop up from nowhere. If you click it, a script will run, doing whatever needs to be done, then clearing the flag field, so the button disappears.
I like to put another “-” button next to it, to just clear the flag if you don’t want to run the script.
Uses
You’re probably saying, “Very cute, but when am I going to actually need such a beast?” It’s a fair question.
You need it when there a certain conditions, and you may or may not want to take an action. You want to be reminded that a decision should be made, but the decision itself is arbitrary; it can’t be automated to run or not run.
Further, the script that would be run could cause havoc if run by mistake. You don’t want an accidental click in the wrong place to run it; you don’t want the choice to even appear unless conditions are right.
It is also useful for navigation, in that you can have a button that goes somewhere only appear when there is actually something at the other end.
Logging Changed Items
The example file show two different ways to log changes to any field and store them in a separate file. The first method uses the above button technique to allow you to choose whether to log a change; the second method logs every change automatically.
The first method requires an automatic method to temporarily store the original item before making a change.
With a little sleight of hand, a short script attached to the Item’s field stores the current amount into a hidden field as soon as the field is clicked, then goes into the field.
Set Field [“ItemStored”, “Item]
Go To Field [“Item”]
The invisible portal method pops up little buttons next to the item. If the change needs to be recorded, you click the “+” one and send it over. If not, click the “-” one and the buttons disappear.
Automatic History Log
You could just automatically log every change to a field or fields. It’s simpler than the above button technique.
The basic script is similar. You don’t need the invisible portal, unless you want to use one for navigation (which I show in the file).
Rather than attaching the logging script to a button, you just attach it directly to the field you want to log.
A script in the log file creates a new record and triggers the lookup, just like before.
You need a script for each field, because otherwise there is no way for it to know which field to return to for data editing; it can’t record the field name and run a script from the same button 🙁
There is more fun stuff with Constant relationships, flags, and buttons in the file. It’s easier to understand by looking at it than reading about it; but here’s my attempt to explain one curious phenomenon.
Constant Confusion (also optional)
Normally, with a flag (or mark) field, you would establish the relationship from the Constant field to the flag field. You’re usually trying to go to just those records that have the flag; Go To Related Record [“Constant::Flag”] will go to the flagged records, if there are any, no matter which record you’re on.
In this case the relationship is the opposite way. Why?
Because Constant::Flag is true if any of the records has a flag. Then the portal relationship is valid and the buttons appear on all records at once.
But Flag::Constant is only true on the records that have a flag; so the buttons only appear on that record.
To make it even stranger, you don’t need to double-click and define the global button fields in the portal as related fields; they’re global, hence always available. You can just leave them as “Current file.” Not only that, you can change them to any relationship; as long as it’s within the file, they’ll still appear on the same records!
You can find those examples on the web of disappearing button fields in Form View, but I seem to have invented using them in List View rows; at least I’ve never seen any. I believe they are limited to using global fields with a Flag::Constant relationships; nothing else will appear/disappear in all the rows. Slight variations are possible in portals.
End out-of-gamut geekiness.
See you next month.
Fenton Jones
Fenton Jones is a FileMaker database designer and consultant, based in San Diego, CA. FileMaker is a cross-platform rapid-development tool for affordable relational databases. If you have need of a FileMaker Pro expert, please be sure to visit his home page at http://www.fentonjones.com
Leave a Reply
You must be logged in to post a comment.