Re: Now is: Finder tell block
Re: Now is: Finder tell block
- Subject: Re: Now is: Finder tell block
- From: email@hidden (Michael Sullivan)
- Date: Mon, 4 Mar 2002 17:28:17 -0500
- Organization: Society for the Incurably Pompous
>
The second really good reason not to use unnecessary tells is execution
>
time. When you use a tell wrapper you send all the commands it encloses to
>
the subject of the tell, even if the command being sent isn't part of its
>
command set. The application being "told" will check every command in it's
>
suite to see if it is there before sending it up the pipe to AppleScript or
>
to a Scripting Addition (assuming it doesn't error as above). This can
>
consume a lot of processor cycles especially if the tell is inside recursive
>
code.
>
Placing a tell within another tell adds yet another layer of commands to
>
check out before you can execute at the "proper" layer.
The testing done by people here (and confirmed by me) seems to indicate
that this is only the case except when using osax commands. For raw AS
language instructions, no event appears to be sent, whether they are in
a tell block or not.
Nested tells also appear to have no significant affect on the speed of
code.
My testing leads me to conclude that what application will recieve a
message is decided at compile time. In the case of osax commands, the
compiler sends them to the tellee rather than the osax when within a
tell block.
There does appear to be a difficulty with figuring out nested tells when
there is a conflict of terminology, but it appears to happen even
outside of the context of nested tells. In fooling around with your
"path to desktop" example, I was able to get the same code to compile
(and run) differently in different iterations.
I have
tell application "Finder"
path to desktop
end tell
returning the result you'd expect outside the finder tell block.
Here's the event log from SD:
tell application "Finder"
path to desktop
--> alias "startup - MES:Desktop Folder:"
end tell
I was also able to get the two examples you said wouldn't run to run,
and the example that should run to not run.
I'm completely in the dark about why it works sometimes and not others.
I also tried fooling around with using tell application "Script
Debugger" directly rather than using "current application"
In any case it does appear that there are some dangers of who gets what
message whenever there are terminology conflicts, but my testing
indicates that those dangers are not restricted to nested tells, but
they may happen at any time in any code! I suspect that either SD or
applescript is caching some terms information about the file so that
when I comment out certain code having compiled it, that affects the
code compiled on the next run.
Very strange.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.