I'm sorry for you. When Filemaker allows me to prepare a macro - er script - with a text editor I might try it again. The idea that one is required to mouse around to make things work is a disaster. You can't even copy and re-use something you did previously in another database.
I completely agree with you, and I'm glad to know not to expend the energy trying to find out if there's a way to do it. :-)
My major use for AppleScript has been to make drag and drop applets which are usually one liners that simply pass a file to perl or perhaps an ANSI-C coded UNIX executable.
I'm beginning to think that's more on the order of the jobs that AS was intended: small stuff. Maybe AS wasn't conceived for developing full-scale applications....
There is a way to put a perl script in a *.app package which can be run from Finder but I haven't yet figured out how to pass arguments.
Heh.. temp files?
A problem with scripting applications with other than AppleScript is obtaining the information you need about the structure of the target application. The dictionaries are bad enough in the script editor and you may find it even harder in perl. Just finding the <<codes>> that are the meat of AppleEvents can be impossible. perl will not fix problems with Filemaker or its documentation.
That is a pretty crucial point. Damn. Truth & completeness in documentation are the only things I really MUST have from a tool. [Oh, and print().]
Thanks for writing - it sounds like your expectations are similar to mine for application development tools. For databases in particular, I may start looking into mySQL as an alternative. For other apps, if their AppleEvents interface can be divined, I will give Perl appleevents a try.
Chap
