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 table "System").
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...
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.
