Hi,
I have several Automator applets with Run AppleScript actions.
Many of them started generating an error after upgrading to El Capitan 10.11 and 10.11.1.
The error massage is: “The action “Run AppleScript” encountered an error”
I’ve been able to narrow down the error to cancelling an AS display dialog box.
This is a test AS script:
tell application "Finder"
activate
display dialog "test run AS in Automator" buttons {"Cancel", "OK"}
display dialog "test 2nd display dialog" buttons {"Cancel", "OK"}
end tell
And this is the corresponding automator workflow:
on run {input, parameters}
tell application "Finder"
activate
display dialog "test run AS in Automator" buttons {"Cancel", "OK"}
display dialog "test 2nd display dialog" buttons {"Cancel", "OK"}
end tell
return input
end run
The workflow must be saved and run as an applet to generate the error when cancelling the dialog.
The second dialog is addd to show that the script continues on “OK” as expected.
Please, can somebody explain why cancelling an AS dialog generates an error in an Automator applet now?
Is this an Automator bug in 10.11? Is there a workaround?
This looks like a bug. Except in the case of ‘choose from list’, it’s normal behaviour for a “Cancel” button to generate error number -128 (“User canceled.”). However, this should simply stop the execution of the script and not set off any alarms.
I notice on my El Capitan machine that cancelling a dialog in a script run in Script Editor now returns a result in Script Editor’s Result pane: error “User canceled.” number -128. On earlier systems, the pane would remain blank.
This doesn’t appear to be cause any problems with scripts saved directly as applets, but it seems that Automator actions are reporting the error.
If the dialog command’s in the script’s ‘run’ handler, a possible work-round would be to enclose it in a ‘try’ block, which would trap the error and cause it to be ignored. Of course then you’d have to include everything after that point in the block too to stop it being executed. Not very satisfactory, but it’s something:
on run {input, parameters}
try
display dialog "test run AS in Automator" buttons {"Cancel", "OK"}
display dialog "test 2nd display dialog" buttons {"Cancel", "OK"}
-- Rest of code.
end try
return input
end run
Perhaps you could take Nigel’s suggestion a bit further, and wrap it like this:
on run {input, parameters}
try
display dialog "test run AS in Automator" buttons {"Cancel", "OK"}
display dialog "test 2nd display dialog" buttons {"Cancel", "OK"}
-- Rest of code.
return input
on error number -128
return missing value
end try
end run
Hi Nigel and Shane,
Sorry for replying so late but I had a stint in the hospital for something minor which kept me bedridden for a few days.
Thank you for your help and suggestions.
Kind of hating temporary fixes which are then forgotten and left there long after the bug has been fixed and staying with medical speak, I decided on major AS surgery:
Being already in the process of updating most of my working scripts which can benefit from the recent AS capabilities such as script libraries, ASObjC, use command, etc. I decided to also drop using the Automator all together and use direct AS applets instead.
Shane, many thanks for the BridgePlus library and the reference to Takaaki Nagoya’s manual.
It is amazing how powerful but clean (bye-bye most tell blocks), readable and to-the-point scripts can be now.