On Jun 24, 2009, at 22:50 PM, Philip Aker wrote: (It will return an error if the event is sent via EPPC, however.)
I'm only vaguely aware of EPPC and restrictions it might have compared to "normal" scripting. Is it that as a rule that no user interaction commands be used, or could one, for example, ask the Finder on the target machine to display the dialog instead of System Events.
Each individual event handler may impose arbitrary restrictions on which events (or parameters, or even specific parameter values) are allowed, including disallowing events that come from another process or another machine. The test for "from another machine" is actually just "was sent via EPPC", aka "remote events". (EPPC events may actually be sent to the same computer, but it's simplest for such a handler to treat all EPPC events as "remote" events.)
In Standard Additions, all the event handlers that display UI return an error for remote events. Currently, the specific error value may vary depending on the handler, but the recommended error number for rejecting remote events is errAELocalOnly (-10016). These Standard Additions don't check which process they're running inside, so it's not possible to tell any process on a remote machine to "display alert" or "choose from list". In addition, "do shell script" also rejects remote events.
Applications and other scripting additions may or may not impose similar restrictions, though it's unlikely that most application event handlers do so. So, if an application supports commands that display UI, they'll probably work remotely. Certainly, any application that can open or make a new document or window will probably allow remote events, too.
(Of course, remote events may still be disabled globally on a given machine.)
-- Chris Page - AppleScripter
The other, other AppleScript Chris
|