PDF Estimated Time To Read This: 4 – 6 minutes
| One of the most long awaited FileMaker Pro features finally appeared in Version 6.0. Custom Dialogs allow the developer to include field values within the dialog text and to accept input from the user in up to three fields. This allows much greater flexibility in providing a truly interactive experience for the user. As with many new features, there are also some pitfalls to be aware of.
As you can see from Fig. 1, it is now possible to use a field’s contents to populate the new dialog. This can be a very powerful feature for informing users of errors, warnings, or the status of an operation.
|
||
| When specifying the custom dialog (Fig. 2), you can choose to pull data from a field or static text. There are still only three buttons that can be defined and their values must be static text. As in the Show Message dialog, the first button is the default. | ||
| Developers have gone to a lot of work designing whole layouts that appear to the user as a dialog floating over another layout. One of the reasons this may have been necessary was to allow the user to enter data in fields. The Custom Dialog feature now allows the user to enter data in up to 3 different fields (Fig. 3). Any of the fields can be formatted as a password field showing only dots. Once the user clicks the default button, the data is written to the specified fields in the current record. The values of the field labels can also come from a field value or static text.
|
||
| There are some things to watch out for with this new feature. First, a dialog with input fields will only commit its data to the record if the user clicks the default button (button one). This is fine if you don’t mind the default button committing data. However, in some cases you may want your default button to cancel an operation such as when creating a new record or performing a lengthy process. If this is the case, having the OK or Continue button as button two or three, the data in the fields will not be written to the current record although the script will continue according to how you’ve written it. The second thing to watch out for is that on the Windows platform the close box of a dialog is always mapped to the default button of that dialog. This means that even if your user doesn’t want to continue a script and clicks the Close button instead of your Cancel button, they may very well end up continuing the script! (Fig. 4) You should also be aware that if you specify a field that may have data in it already, that data would show up in the dialog allowing the user to change it or keep it.
|
||
| Also, any data entered via the Custom Dialog fields is not subject to field validation or even field format validation. In other words, if you have validation that a field’s value is to be unique, you will be allowed to enter non-unique values via the dialog fields and no message will inform the user that the validation has failed. It is therefore important to validate the data within your script before it’s committed to the record. Entering an invalid date or time field is possible through these fields, so ensure that this is also captured in the script.
The Show Custom Dialog script step is certainly a very useful feature but care must be taken when using the data input fields, especially on the Windows platform. |
||
