AppleScript and FileMaker
FileMaker can be a powerful platform for a number of applications, and one of the keys to leveraging that power is through integration with other applications in a way that compliments the strengths of each application. AppleScript is one of the many tools that, when combined with FileMaker, can produce fantastic results.
FileMaker does offer a scripted method of running AppleScripts from within a solution, and it has enough functionality to use for very simple processes, however, there are several limitations to running an AppleScript via FileMaker script step. Normally, AppleScript will operate similarly to how a FileMaker script works; each step will complete sequentially, waiting for the previous step to finish before moving to the next. When running via script step I have noticed that this may not always be the case. AppleScript via script step seems to have many challenges when it comes to the timing of events. This limitation makes it exceedingly difficult to utilize the perform AppleScript script step for any complex multi-step AppleScript. So, to make things a little easier for everyone trying to use AppleScript with FileMaker, here are a few tips and tricks I’ve picked up along the way.
1. Always know where you are
AppleScript can be prone to an error that FileMaker rarely has issue with; timing errors. I have found that there are two methods that work very well in avoiding timing problems. The first is a busy check, and the second is a step-based approach. A busy check is just what the name implies; you check to see if FileMaker is “busy” (running a script, in a modal window, etc) by attempting to perform another action. Generally I do this by running a blank script. If the “Do Script” function returns an error, you know that your previous action has not finished, and you can wait an appropriate amount of time to test again before moving forward. The other technique requires that your AppleScript be segmented into steps, each one containing a single action which can be repeated if it should fail. After each step, you test to see if the desired effect has taken place, and if so, you move to the next step. These are both very basic concepts, but for those of us who are used to FileMaker scripting, these may not be ideas that we are used to using.
2. Moving Quickly
As in FileMaker, there are a handful of ways to perform every task in AppleScript. A lot of the choices you make will depend on your particular style of coding and your preferences and ability. Below you will find some of the pitfalls that you will want to avoid when dealing with FileMaker via AppleScript
1. “Click” is not your friend. For UI scripting, the “click” function is one of the bread and butter commands. However, for an unknown reason, using this function in FileMaker to click on UI elements can cause brief periods of hang time. (up to 7 seconds in some instances!) Instead, try setting the focus state of the UI element to true and send a spacebar keystroke.
2. Nested tells can make your code look more structured, but all it will do is make your code more difficult to read because of the added length, more difficult to modify because of the added complexity, and it will make it extremely easy for you to make a syntax error, but extremely difficult to find said errors, as you’ll be forced to match up hundreds of tell/end tell pairs.
3. When you have a hammer, everything starts to look like a nail. This is the case in AppleScript as well. AppleScript can do a lot of things, even in the FileMaker world! But when it comes down to it, some things are best left to FileMaker. For instance, there are script steps to open nearly all of the FileMaker menus, open and close files, and a huge number of other actions. Use them! It is a lot easier to test to see if a “Do Script” command has completed than to test for five or ten intermediary steps.
3. Avoiding Errors
I wish there was some simple little trick that I could give to avoid all errors! That may not be the case, but I do have some techniques that will make dealing with errors and predicting errors a lot easier.
1. Using “Try” blocks can make it very easy to enact a step-based approach. Many errors, specifically timing errors, can be solved by simply trying again. Using a try block to return to the beginning of a step is an easy way to keep your script moving forwards, although it can cause some infinite loops, so watch out!
2. We touched on this before, but use FileMaker scripting when it makes sense! It can be a lot less prone to error, and in many cases it will be a lot faster.
3. There are some errors we simply cannot fix when dealing with FileMaker. For instance, if a file has been uploaded to FileMaker server, but you are still working with the local file, you will get a prompt when opening that file which asks if you want to use the local version, or the hosted version. Unfortunately, there is no way to detect this! Because this is actually part of the “Open file” command, your AppleScript will not move past that point until the prompt is dealt with.
Using AppleScript with FileMaker can be frustrating and difficult to troubleshoot, but it can also be very powerful. Using Goya’s RefreshFM, we at DocuWrx have created an end-to-end fully automated update procedure using only AppleScript and FileMaker which has cut the number of errors in updating down to nearly nothing, and allows us to update batches of clients with very little oversight. Hopefully these tips will help you use AppleScript and FileMaker to their full potential.