We’re continuing our discussion of the new FileMaker 19 add-ons. Claris has released a great video on these add-ons, but, in this series of posts, we’re taking a deep dive into how the add-ons work. In this post we look at how to use multiple instances of the FileMaker add-ons.
The Point of the Add-ons
One of the biggest reasons to use an add-on is that it can be used many times throughout your file. Just like a portal or a button bar, the calendar add-on or the photo gallery add-on is flexible enough to use all over.
As a FileMaker developer you don’t have to know how this works; just know that it works. Your use of an add-on multiple times in the file will not disrupt any of the other add-ons. Here’s a silly example.
Two Timers To Track Times
These two timers are separate instances of the same Timer add-on.
They work with two sets of the timer’s required fields. They have their own configurations (one has a blue button/gray background, and the other has a red button/white background).
Each add-on runs independently of each other; indeed, you can kind of see it here (in the button text), the first timer is running and the second timer has stopped.
Each Timer is Unique
The magic behind this idea is that each timer is given a unique Addon UUID when you drag/drop the add-on to a layout. You can see this unique ID in a few places:
- The add-on’s FileMaker buttons (such as the configurator button or the back/forward arrows) script parameter
- The name of the web viewer object in the Inspector
- The web viewer’s calculation
Of course all of these match, and have a specific purpose.
Multiple Instances of FileMaker Add-ons: The Deets
Let’s make sure we have something clear in our heads:
- When we install the add-on, all the scripting, layouts, etc comes in as a complete package. The scripts come in once.
- When we drag/drop the add-on onto a layout, we’re creating a new and unique instance of it. The UUID gets generated and attached to the places you see above.
- If you were to copy an add-on, you’re copying the UUID as well, so there will be two add-on groups with the same UUID. Can’t have that.
Now that we have that clear (if not, go back and read it again), all add-ons of the same type use the same scripts, so the UUID is passed to scripts to let the script know which one to work with in some manner. The “Show Config” script gets the UUID attached to the button and grabs the config from the ConfigStore field using that UUID. Because the web viewer is named with the UUID, the script knows which web viewer on a layout to activate and manipulate.
This idea of the UUID is incredibly important. You don’t want to change it, unless you want to go to the trouble of updating it all over.
The Only Other Thing
I believe the only other thing you really need to know about multiple instances and the UUID is the script containing the words “WebViewer Object Name”. This script generates the web viewer’s name at runtime, and is used in almost every add-on script. Just FYI.
Oh yeah: if you really want to know how the UUID is generated, I explain that in the post on creating add-ons. Check that out.
Go Forth and Multiply
So use add-ons all over the place. Use a timer ten times in your custom app. Build a dashboard using charting add-ons. Create a layout with two Kanban boards that show different tasks. You got it! It’s easy and the add-ons are built with this in mind.