D is for dialog
A dialogue (or dialog) is a conversation, talk, discussion or chat.
In computer terms, a dialog box (or simply, dialog) is a small window that communicates with the user, giving them options (via buttons) or allowing responses (as text).
Here is an example of a dialog seen in macOS when you empty the Trash via the Finder menu:
Dialogs are often classified as modal or non-modal. A modal dialog will block any further action in the application until the dialog is dealt with.
Did you know?
Menu commands that end with an ellipsis (…) will proceed to a dialog; those that do not, immediately execute the command. For example, in FileMaker Pro, the Records menu has a number of commands followed by an ellipsis including the destructive Delete Record… and Delete Found/All Records… commands!
Native FileMaker Dialogs
When using FileMaker Pro, any user will see a range of native dialogs – those that are generated by the application rather than by a developer. These dialogs are built into processes such as record sorting, importing and printing.
As mentioned above, one type of dialog is that seen after choosing a menu command (or using the shortcut). Where the command is destructive, the default option is to cancel.
Another sort of dialog is an error as a result of a process the user runs. For example, if the user performs a find and no records are found, the user can cancel the process or try again by modifying the find request.
Some FileMaker dialogs are more complex, allowing the user to make a number of choices before proceeding. One example is the Sort dialog, which may be a simple ascending sort by one field, or a complex multi-level sort using a summary field to re-order groups:
Native dialogs may also be displayed when validation field options are set and a validation rule is broken. For example, if a field has validation to require it to be “Not empty”, leaving the field blank may result in the following dialog when the record is committed:
Native FileMaker dialogs cannot be customised by the developer. Sometimes, they are not intuitive for all users – they may communicate the wrong message, be difficult for the user to understand, or provide unnecessary options.
Custom Scripted Dialogs
The majority of custom dialogs in FileMaker solutions are created with the Show Custom Dialog script step. This allows the developer to craft a message and to provide up to three buttons for the user. The button clicked by the user can be queried with the Get ( LastMessageChoice ) function and conditional actions performed as a result.
The custom dialog also allows for up to three text input fields. This allows the user to enter data into fields through the dialog. The input fields are specified and can be labelled in the dialog by the developer. There is an option to use the password character (•) to obscure input.
Did you know?
The result of the button choice for a custom dialog will persist in a script until another custom dialog is presented or until the script ends. This means that the Get ( LastMessageChoice ) function does not need to be invoked immediately after a dialog.
Changing the Message
If the developer is not confident that the user will understand the native validation message shown when a rule is broken, they may craft a clearer message.
For example, a rating field may have validation set that it must contain a value that is a member of a value list. If that list contains the numbers 1, 2, 3, 4 and 5 and a user enters 2.5 or 6 in the field, they may see the following validation dialog:
It is not clear to the user what is a ‘valid’ value. And they may not understand what the Revert Field option will do. So the developer may opt for a custom message:
Did you know?
When crafting a custom error message, it is important to do two things – let the user know what went wrong, and give them options to fix it.
Suppressing FileMaker Dialogs
A FileMaker developer can suppress most of the native FileMaker dialogs that arise, and they can provide their own dialog for the user.
In scripting, the Set Error Capture [On] script step will suppress native FileMaker error dialogs. This does not mean that the error does not happen – simply that the dialog is not shown. This is useful when the error needs to be handled in a particular way.
One commonly captured error is that where no records are found. In many scripts, the Find process is built in and not actually performed by the user. So a message stating that no records were found would be confusing.
In that case, the developer can use script steps to test how many records were found and then act conditionally on the result. For example, it may be reasonable that if no records were found that a new record is created. This could be done without involving the user, or they could be shown a dialog stating what happened and giving them the option to create a new record.
Did you know?
The Get ( LastError ) function is used to retrieve FileMaker error codes. A commonly trapped error is 401, meaning “No records match the request”. When no error occurs, the error code is 0.
Many script steps provide the option to suppress the dialog. This is often used when the action should be automatic and the user would not necessarily know what settings to apply. Examples of script steps where the dialog might be off are Sort, Print Setup and Export Records. In these cases, required settings would be stored for each step. The Print step will usually present a dialog.
When you need to inform your user or get information from your user, dialogs are the way to go.