On Apr 30, 2015, at 9:21 AM, Yvan KOENIG < email@hidden> wrote:
(2) We are warned for 3 or 4 years that call to OSAX functions are not allowed to be in tell application blocks.
To clarify: the recommendation is to use tell-application blocks judiciously and to put only the required code inside them, so that you aren't unnecessarily sending events to the target application when they could have been handled in the application process running the script. For example, there is no need to ever send "current date" or "random number" to another application†.
When you put commands in a tell block, they are sent to the specified target. So be sure you mean it. Even if it ultimately works, there's a lot of CPU overhead, which can slow down scripts.
It should rarely be the case that you need to execute "info for" in another process. The only reason that would be necessary is if the other process has access rights that the sending process doesn't have, so only it can read the file info. If that's the case, you really should be using a mechanism like "do shell script … with administrator privileges" (within the application that's running the script) so you can formally declare that you need additional privileges to read the file.
Nowadays, scripting additions can have a "Context" attribute that tells AppleScript and OSA (which manages receiving scripting-addition events in the target process) where they actually need to run in relation to the application sending the event and the application receiving the event in order to produce correct results.
For example, "random number" declares that it can run anywhere—there is no need to ever send it to another process. When a "random number" event is received, OSA rejects it and returns a privilege-violation error. AppleScript then looks at the event's Context and sees that it can successfully run in the sending process and so AppleScript invokes the scripting addition's event handler in its own process. But only after sending a completely unnecessary and unsuccessful event to the other application.
"info for", however, *may* in fact need to run in the target process. There may be scripts out there that need to use the access rights of the target process to read the file information. To avoid breaking existing scripts altogether, "info for" has a Context that says it needs to run in a process owned by the same user as the target process in order to guarantee it will be able to read the file. If the sending process and the receiving process have the same owner/user ID, as with "random number" OSA will reject the event and AppleScript will handle the event in its process. However, if the target process has a different owner, and therefore the result could be different from the result it gets when running in the sender, OSA replies "I've rejected this, but I'll accept it if you can prove that you're an admin user". Then, AppleScript prompts the user to gain admin authorization, and if the user successfully authenticates, AppleScript sends the event a second time, this time including an "access right" token to prove it has the right to use the target process' user's privileges to read the file info.
Similarly, "display alert"'s Context declares that it needs to run in the target process, because scripts expect to display a modal dialog in the target application that blocks user interaction with the application. This is true of most of the Standard Additions that display windows.
Finally, even when an addition declares that it needs to run in the target process to produce correct results, there are some rules that will reject the event outright and not allow authorizing as an admin user. The OP may have run into one of these situations.
The executive summary is: don't send events to another application unless you mean it. Don't put them inside a tell-application block unless you need to execute it within the other application process. (Or prefix it with a "tell me to …" or "my" to ignore the current target of the tell block.)
† You may want to send "current date" to another machine to see what date-time it has, but every process on a given machine will produce the same result, so there's no reason to send "current date" to another process on the same machine. While it's conceivable that *someone* may want to send "random number" to another process in order to share its random-number seed, it is highly unlikely, so I made the executive decision to always disallow sending "random number" to another process, by setting its Context to "Any" (which means "it behaves the same in any process for any user on any machine"). If your script has a "use" clause, thereby opting in to newer behaviors, AppleScript will notice events like "random number" that have an "Any" Context and therefore will never be handled by another process (they will always reject it outright) and will avoid sending it in the first place. However, for compatibility with existing scripts that are liberal with their use of tell-application, most Standard Addition events are still sent to the target first.
-- Chris Page The other, other AppleScript Chris
|