AppleScript's Scripting Additions dictionary contains a number of useful dialogs (e.g. "display dialog", "choose file", "choose from list"). As with most dialogs, the user can cancel and go on with something else. But, when the user presses the "Cancel" button or presses the "esc" key, the dialog returns an error -128.
Why is it so ?
This can be controlled with some dialogs by defining the buttons to be e.g. "No" and "Yes". The AppleScript code can then respond appropriately to the "No". That avoids the issue but at least, then, there is no need to put the "display dialog" into a try block.
But, the buttons on some dialogs cannot be customised e.g. "choose file name". So, every time those dialogs are used, they must be wrapped in a try block so that the script can deal with the user's cancelling of the dialog.
Instead, why not return a "Cancel" or a boolean "false" ? If the user presses the "Cancel" button why not return something to indicate that instead of banging an error that has to be trapped ? For example for display dialog it could be {button returned:"Cancel", gave up:false} and for choose file it would be [missing].
I guess that changing this after so many years of people crafting scripts around it would be risky. But, why do those dialogs have to return an error ?
Why is it so ?
Because the folks who designed AppleScript back in the early ’90s decided to make it work that way.
If you find this annoying, wrap the call with your own code that supports the interface you prefer. For example:
on displayDialog(message)
try
display dialog message
on error
return {button returned:"Cancel"}
end try
end displayDialog
Oh, and you can reliably detect a cancel with this code:
on error errMsg number errNum
and then checking errNum for -128 (this is the traditional Mac OS userCanceledErr).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"