FileMaker 17 was released this week, and LuminFire has a series of blog posts highlighting our favorite features. Be sure to check out the other posts and keep an eye on our blog page for the latest news.
This feature is one that I would call a “sleeper” feature. It may seem like a minor change, but it will have a huge impact on how we code things in FileMaker, moving forward. It’s an enhancement to the Show Custom Dialog script step: we can now specify a variable to use for user input fields. Hooray!
The Show Custom Dialog script step
To review, the Show Custom Dialog script step allows a script to show information to a user in a dialog box, and ask for input from the user to implement script branching. Think of it as the FileMaker version of Choose Your Own Adventure! We can specify up to 3 buttons, and take different actions based on those choices. Here is the main tab of the Show Custom Dialog options window:
This is what that dialog would look like to the user:
We test using the function Get ( LastMessageChoice ) to detect if the user clicked button 1, 2, or 3. Note that in the options dialog, they are listed in order top to bottom, with button #1 labeled “Default Button” and the custom dialog displays the button in order from right to left, per standard user interface design patterns. This may be different in different countries or localizations. Here is a basic example of script branching, based on the user button selection:
OK, then what has changed?
There is one more area of options that we didn’t get to yet. The Input Fields pane lets us ask the user for input beyond just a button click. It presents up to 3 fields for the user to enter data. Up until now, we had to have a field to collect that data. Sometimes that is convenient – we can ask a question and have the user enter data directly into a field via the custom dialog. This is helpful when the field in question isn’t visible or editable on the current layout, or the script workflow takes the user out of the normal data entry layout. But what if what we are asking doesn’t belong in a field? Or if the script needs to do some validating or processing before we allow the data in our field? The standard work-around has been to use a global field to capture the user input as a temporary holding place. But now in FileMaker 17, we can specify a variable instead.
This is what we see now when we check the box to show an input field or click on one of the Specify buttons:
We can still choose a field if we want, but we now have the option to specify a Variable. Just like a field as input, if the variable already exists in the script with a value, that value will be present in the field when presented to the user. Here is what the dialog looks like now, with a pre-populated variable:
Why you should start using this feature now…
The first advantage that comes to mind is that we no longer need to clutter up our database schema with global fields dedicated to the purpose of user input in scripts. But the other advantage is much more profound: scripts that use custom dialogs just became modular! While it may not seem like a big deal to add a field to support your script, that means that your script has a dependency. If you want to re-use that code in another file and you copy and paste your script, things will break if the other file doesn’t have a table and field with the same name.
At LuminFire, we try to build as much of our code as we can in a modular fashion. There are countless occasions where I’m working on a client’s app and have a need for a similar process that I’ve already done for someone else. Rather than spending time reinventing the wheel, I’ll borrow code from the other file, so I can move on to solving the next problem.
Things to keep in mind…
- The variable that you specify can either be a local variable (prefixed by one dollar sign) or a global variable (prefixed by two dollar signs). A local variable’s scope is only within the current script. A global variable can persist beyond the current script.
- Each button in the Show Custom Dialog options has a checkbox to
Commit Data. This controls if/when data is committed to the field or variable. If the checkbox is not enabled for a button and users enter data in the input field, no data is committed to the record or stored in the variable when users click the button.
If you would rather focus on running your business than worrying where to store user input, let our brilliant developers build your business-critical custom software. Contact us today to get the conversation started.
[Japanese translation]