This is certainly a solution, although it's not perfect for two
reasons. One is that you need to have specific field names known to
both the script and to the FileMaker application (which is not robust
because you have to remember never to change the names of the fields,
or you have to pass the name of the field to the AppleScript.
Yes but my simple solution there is that I always create same-named
fields for this purpose in every database where I'm using AppleScript.
So my references are always the same (typically: cell "zz__Result" of
Ditto. You only need to do this a few times and you'll never forget.
But the bigger problem is that to capture all errors basically means
putting a "try/end try" bracket around your entire applescript
application, which makes it difficult to debug...
I use libraries, others use applications to perform complex jobs run
via FMP. The code is tried and true and easy to upgrade because it's
not stuck inside FMP.
True I suppose ... but I've found I tend to develop the AppleScript
outside of FileMaker (usually with Smile) until I'm happy enough it's
working, and the error trapping is added for parts (such as
controlling other apps) that may cause problems. In practice, I've
been able to get reliable enough systems for our use, but your systems
may be more hands-off than ours.
In most real, live situations the job is either done or done. If it's
not done the user has to know.
If it's batch processing that takes place without user interaction, the
application has to be able to go onto the next item. In this case you'd
have implemented a logging function that tells you want has happened,
when, why and how.
In either case, you write code that works, and that includes testing
for error conditions.
T: 0403 972 660 E: email@hidden
FOR YOUR COMPUTER Customised software built to your specifications.
Using Macs? Automate your workflow with AppleScript. FOR YOU Computer
training, software installation + upgrades, computer setups. IN TIMES
OF NEED Troubleshooting, maintenance + repairs.