I’ve found a bug that I’d like to see if anyone else has verified - when trying to execute remote handlers via eppc from a Snow Leopard machine, it fails with:
error “SimpleHandlerApp got an error: Can’t continue sayStuff.” number -1708
where “sayStuff” is the AS handler attached to the “SimpleHandlerApp” application. I’ve filed a bug with Apple but it hasn’t been looked at. Here’s the text of the bug report that contains a full description of how to reproduce:
When trying to execute an attached script handler on a remote machine FROM a Snow Leopard machine, you get the following error:
error “SimpleHandlerApp got an error: Can’t continue sayStuff.” number -1708
Steps to reproduce:
On machine 1, create the following script in Script Editor:
on sayStuff(theMessage)
say theMessage
end sayStuff
Save it as a Stay Open script application with the name “SimpleHandlerApp” (or whatever)
Start it running
Make sure that you have Remote Apple Events turned on in the Sharing system preference pane
On a remote Snow Leopard machine, run the following script in Script Editor:
tell application “SimpleHandlerApp” of machine “eppc://USERNAME:PASSWORD@IPADDRESS”
sayStuff(“Hello”)
end tell
You get the error
If you follow these exact steps but do step 5 on a Leopard/Tiger machine, it works.
I know there were significant changes to how AppleScript security works - maybe I’m just doing something wrong?
I’m having exactly the same problem-- several scripts that have worked fine for years suddenly broke after upgrade to 10.6. I’ve tested several configurations and cannot get a remote apple event to work at all: always fails with “can’t continue, error -1708”. I"m authenticating as a user with administrator privileges, the same user that is currently logged in on the target machine (and the target application, a stay-open applescript, is running under that user).
a handler call in an application tell block normally produces the can’t continue error.
It’s seems to be a bug in Tiger and Leopard that this error doesn’t occur
As a handler call belongs to AppleScript itself, you have to refer to AS with the keyword my
tell application "SimpleHandlerApp" of machine "eppc://USERNAME:PASSWORD@IPADDRESS"
my sayStuff("Hello")
end tell
Using “my” would imply that the local script has a handler called “sayStuff”, which it doesn’t. The remote application defined the handler, not the local script, so using “my” isn’t appropriate.
It wouldn’t help - “my” is used to escape any current tell blocks so that the statement following the “my” will target the script in which it is running (in our example, the local script). This obviously isn’t what we want: we want the script handler called that’s defined in the remote application (the application that’s the target of the tell).
It doesn’t appear that this is a generic scoping error since you can tell an application to execute it’s built-in actions - for instance, this works:
tell application "iTunes" on machine "eppc://USERNAME:PASSWORD@IPADDRESS"
playpause
end tell
So it’s something more to do with script-defined handlers that are attached to the application.
I was hoping 10.6.3 would fix this but apparently not. Is it simply not possible to use an applescript to handle an event from a remote application now?
My bug on bugreport.apple.com has had no activity since I filed it. Looks like we’re out of luck. If anyone has any contacts inside Apple now might be a good time to use them…
My example above doesn’t use any scripting additions.
[EDIT]OK, I suppose the say command is, in fact, an osax. But, to answer your question, yes, you can substitute anything you want in there and it will generate the same error.
[EDIT2]Simple examples are really hard to come up with because there are very few attachable applications, but if you’re interested in trying it out, download Indigo (our home automation application) and register for a trial version. Once you have Indigo up and running, do the following in Script Editor on a remote Mac:
I get where you were going - maybe the security is violated when the remote application tries to communicate with another app (or osax). Unfortunately, that’s not it. The handler above, iTunesLog, doesn’t actually attempt to talk to iTunes, it’s only a handler wrapper around the built-in Indigo “log” command.
That works. Unfortunately, all it really proves is that a stay open AppleScript doesn’t behave like an attachable application. If you’re really interested in trying it out, you have to test it with an attachable application:
Download Indigo (our home automation application) and register for a trial version. Once you have Indigo up and running, do the following in Script Editor on a remote Mac:
tell application "IndigoServer" of machine "eppc://USER:PASS@HOST" to iTunesLog("Testing")
I get where you were going - maybe security is violated when the remote application tries to communicate with another app (or osax). Unfortunately, that’s not it. The handler above, iTunesLog, doesn’t actually attempt to talk to iTunes, it’s only a handler wrapper around the built-in Indigo “log” command:
on iTunesLog(logString)
log logString using type "iTunes Attachment"
end iTunesLog
The “log” command is built-in to IndigoServer. It does appear to be a clue however. Do you know why executing OSAXen in that fashion doesn’t work?
Actually, I have an extremely simple 3-step example to demonstrate the problem:
on the host machine (which can be running 10.4, 10.5, or 10.6, it doesn’t make any difference) compile and save the following as a stay-open application named “remoteTest”
property someCharacters : “ABCDE”
on getACharacter(x)
return character x of someCharacters
end getACharacter
Launch this application on the host.
on the client machine, enter and run the following in script editor:
tell application “remoteTest” of machine “eppc://user:pass@hostName.myDomain.com”
return getACharacter(3)
end tell
That’s it. If the client is running 10.5, it works fine (returns, in this case “C”, the third character). If the client is running 10.6.x (including 10.6.3), Applescript editor reports “Can’t continue… error -1708”