Re: Filemaker 8.5 stored applescript problem
Re: Filemaker 8.5 stored applescript problem
- Subject: Re: Filemaker 8.5 stored applescript problem
- From: "Stockly, Ed" <email@hidden>
- Date: Sat, 19 May 2007 13:00:26 -0700
- Thread-topic: Filemaker 8.5 stored applescript problem
This is becoming the thread that won't die, so just skip it if you're bored, but I've learned a few things here and I've found it helpful....
>>> always thought this problem was unique to FileMaker; a bug. But if it can happen in any app, then I¹d call it a bug in AppleScript.
Not just any app, but only those apps whose developers choose to implement the "feature" that allows a script to be loaded internally without the need for the "tell application" construct, and then, only if there is a terminology conflict.
And I believe the scripts run faster in this context, it's not done by accident. And the terminology conflict is the real problem, the context the script is running in only made that harder to determine.
>>>If there was a true 'containment' hierarchy, then the compiler would not be able to match a constant name to a command name
This is purely a compiler issue. The compiler reads raw text then runs through the text figuring out what's a command, what's a class, what's an object, etc. ect. And the compiler is not that smart either, so if it comes across a string that simply says "read" it first looks in the application dictionary for that term, and compiles if it finds one. I think it starts in the application dictionary, then scripting additions then the language. The "tell application" and "using terms from" contructs force it to start outside the application dictionary, in another app's dictionary, where there is no conflict.
That's why appleScript terms have to be unique and are often two or more words "open for access" would be an example of a single term consisting of multiple words. It won't cause a conflict with an application "open" command, for example.
Back in the bad old days apple had an AppleEvent Registrar who would keep track of OSAX terms to avoid these conflicts. (I think he still lurks on this list, we hear from him every now and then)
>>> they should be two distinctly different object types.
They are, but the compiler, reading raw text, has no way of knowing what the object type is.
>>>And how is the compiler supposed to know which ³read² object the developer wants?
The developer needs to use unique terms in their dictionary. "read object" or "read data" would be better (the complier looks for multiple word terms first).
>>>1) hope it never happens, but if it does then deal with the downtime, troubleshooting the issue, and calming the panicked client after the fact; or
>>>2) be proactive and revisit all those scripts and strengthen potential problem areas with ³tell app² or ³using terms² clauses.
I really don't think these things come up out of the blue. I don't think working scripts suddenly break. Even the most cursory testing will reveal this problem.
Plus, given all terms in all the applications and all the scripting additions, I think it's pretty remarkable that the number of terminology conflicts is so small.
Here's a little testing I did:
------------
--requires Jons commands
set startTicks to the ticks
tell application "Finder" to activate
--tell me to activate
repeat 1000 times
tell application "Finder"
--activate
ASCII number "x"
end tell
end repeat
set endTicks to the ticks
set firstTest to endTicks - startTicks
tell me to activate
--tell application "Finder" to activate
set startTicks to the ticks
repeat 1000 times
using terms from application "Finder"
ASCII number "x"
end using terms from
end repeat
set endTicks to the ticks
set secondTest to endTicks - startTicks
tell me to activate
--tell application "Finder" to activate
set startTicks to the ticks
repeat 1000 times
ASCII number "x"
end repeat
set endTicks to the ticks
set thirdTest to endTicks - startTicks
return {firstTest, secondTest, thirdTest}
--{183, 13, 14}
Not scientific, this shows why I'm not all that concerned about sending OSAX commands to an application.
You really have to be in the hundreds of repetitions to really get a descernable difference in speed, and if you're at 1000 reps you get less than 3 seconds additional execution time, with this command.
The good news is the "using terms from" contruct doesn't add any time at all to the execution, and I'll probably start using that when I am processing a large number of commands.
HTH
ES
<<winmail.dat>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden