Another great new feature in FileMaker Pro 17 is a new way to set variables – through a custom dialog.
Show Custom Dialog
This script step allows a script to interact with the user, providing feedback and allowing input. The script step options provide two tabs – General and Input Fields:
When input fields are used, these are presented on the custom dialog for user input. The field can have a label (static or by calculation) and can be presented using password bullets to obscure input.
Before FileMaker 17
The problem before FileMaker 17 was that the input from these custom dialogs was limited to a field. Depending on the use case, FileMaker developers create global fields for the purpose of storing custom dialog input. While these fields could be in any table, they still needed to exist in the schema and be managed.
When clicking the Specify… button for an input field in FileMaker Pro 16, the only option is for a field:
Example
Here is an example of a script in FileMaker Pro 16 that allows a user to reset their account password.
It presents a custom dialog (line 4):
The user input is stored in repetitions of a global field (password_g). These are checked to ensure that the passwords match exactly (line 8). If so, then the account password is reset using one of the global field values (line 9).
Importantly, all global field values are cleared at the end of the script (lines 20-22). These will be cleared at the end of the user session but, for a number of reasons, they should be explicitly managed in the script.
New in FileMaker 17
The same Specify… button in FileMaker Pro 17 provides the choice to specify a field or a variable.
Notice the subtle difference in the title – Specify Target. Note also that FileMaker has added the ability to search for a field if you are using that.
Now there is the ability to enter a variable name (either local $ or global $$) that will be used as the target for user input.
The Repetition applies to either the field or the variable that you specify. However, if you want to use a repetition for a field, it must be defined in the field options.
limitation
This is minor – the variable name must be hard-coded. There is no option to calculate the variable name through a Specify button. This is the same as when a variable is set using Set Variable. In both cases, it would be useful to be able to set a calculation to specify the name of the variable to use.
Example
Here is a modified example of the script for FileMaker Pro 17 that allows a user to reset their account password. The custom dialog presented is exactly the same.
Note that variables rather than fields are being used in lines 2, 4 and 9. And there is no need to clear the variables at the end of the script – local variables are used that disappear when the script ends.
Backwards compatibility?
Obviously, there is no backwards compatibility for this FileMaker 17 feature. If you open the above script in FileMaker Pro 16, you will see <Table Missing> in the Show Custom Dialog step (line 4).
So what?
Why is this a great feature for FileMaker Pro 17? It allows the FileMaker developer to remove global fields from the schema since custom dialog input can be handled through variables. And, unlike global fields, local variables are self-managing – they disappear at the end of the script in which they are used.
New Feature Request
While this is a great new feature, we might need another one – a layout object that can be used to set a variable. This would probably look like a standard edit box (field) and provide all the same options for presentation and input like using value lists.
The reasoning here is that FileMaker developers need more flexibility with dialogs than is provided by Show Custom Dialog. Developers are using card windows for user dialogs. This allows them to specify dialog size and position and to use any number of layout objects in the dialog layout. However, this currently means that values can only be set in (global) fields. A layout object that sets a variable would be great!
If you like this idea, you can go to the FileMaker Community and vote for it:
2 Responses
I’m missing something. Since you can use a button bar segment to specify a calculation, surely that counts as a layout object that allows you to set a global variable – e.g. Let ( $$var = foo ; “” )
If you control script execution while presenting the layout, you can have it be a local variable instead, if you prefer.
Yes you can do that but it is limited to setting a specific value. There is no user input.
The new feature request is about the flexibility of setting a variable. I need to be able to enter any value into an object (that looks and behaves like an edit box / field) to set a variable.
For example, I could bring up a card window and have the user fill in any number of “fields” for a new record. What they are actually doing is setting a whole bunch of variables. These can then be used in processes to check for existing records, validate data, etc., before creating a new record. No global fields required. Cool?