This blog post covers the 2nd half of the “Modular FileMaker” series. If you haven’t yet, check out the first part in the series here and check out another post highlighting a couple of modules we have used from ModularFileMaker.org.

In the previous post, we discussed the basic principles of modular development and applying those principles to FileMaker development. In this post, I’m taking a module I’ve created and restructuring it to fit within the guidelines at ModularFileMaker.org for public use as a mFM (modular FileMaker) module.

Dialogs are nothing new. As a developer, it’s the primary form of developer-to-user communication. FileMaker’s “Show Custom Dialog” functionality is great for showing errors and gathering bits of input before, during, and after a call stack. Dwayne Wright has written an excellent bit on using this functionality. FM’s dialog does come with its own set of limitations. There are times when a dialog would be helpful, but the “Show Custom Dialog” script step is not exactly suited for the situation. First, FM’s dialog waits for user input, pausing the script until input has been received, but user input is not always necessary. Second, if a script is running that, for one reason or another, requires time to complete, the user is stuck in this “waiting state” with no clear indication of what the current script is doing. They may see an asynchronous progress indicator or Spinning Wheel of Death (or SWOD, as the kids say), but no real indicator that something is supposed to be happening. Third, FM’s dialog window size and location is stored within the confines of the FileMaker Pro app library, not controllable by the developer.

The “ModularDialog” module can be used to display a dialog while allowing for little to no user interaction. Designed to be easily copied into a solution, it uses a few basic FileMaker objects, a slide control panel, and one simple script used to show or hide the dialog. To stay within the mFM guidelines, there were a few points I had to keep in mind when building this module for use on mFM:

• Limit the use of custom functions. Custom functions are highly useful, but can be difficult to troubleshoot and can limit the adoption of mFM modules.

• Limit the use of plugins. As with custom functions, adding plugins to a module can add a level of complexity that may not be necessary.

• Include a README script with the instructions on how to install the module and explain any dependencies.

• Include a script that tests the installation and setup of the module.

• Although the ModularDialog module is lightweight, I decided to retain the folder structure listed in the mFM documentation, in case this module is ever extended down the road.

The ModularDialog scripting is built around a single Let variable:

Using a Let calculation allows for multiple parameters to be passed into the script, while keeping the calculation simple enough for anyone to edit, regardless of skill level. More detailed examples can be found in the mFM documentation.

Using the module is simple. Copy and paste the grouped object onto any layout, then copy and paste the module script folder “ModularDialog”. The objects are grouped in a particular way so it can be easily resized. Call the script “ModularDialog” and pass the text to be shown in the dialog. To clear the dialog, click the dialog box or call the same script and pass empty variables (“”). For example, to hide the dialog after a number of seconds, use the “Install OnTimer Script” to call the “ModularDialog” after the specified interval. The included script “ModularDialog Example” gives an example of how to show and hide the dialog, using the “Install On Timer” script step.

We’ve already found some unexpected use-case scenarios for the ModularDialog, like using it as a progress indicator by calling it multiple times during a script that sets a number of records in a found set. Download it for yourself, give it a go, and let us know of other use-case scenarios!

The ModularFM page can be found here and the module file can be downloaded here.