When one uses the default answer parameter in display dialog in AppleScript, whatever text is set to default answer is automatically highlighted upon display of the dialog.

Is it possible to specify a default answer without the answer highlighted?

I would ideally like the cursor to be placed after the last character of the default answer, so that the user can append text to this answer without first pressing the key (or, worse, accidentally overwriting the default answer).

  • I don't think it's a good UI practice to use a custom answer as the default answer. A default answer should be either yes or no but not no, but ... (or yes, but ...).
    – klanomath
    Commented Mar 3, 2017 at 20:03
  • @klanomath The dialog in question does not receive a yes/no input from the user - it receives a keyword. Depending on the user's intent, the default keyword will sometimes be sufficient. Other times the user will want to remove the keyword entirely. Most times, however, the user will want to append text to this keyword (which is why I want the default answer to be unselected, so that the user can immediately append text without having to press the right arrow key first). Employing a default answer is the most efficient way for me to offer all of these options at the user's fingertips. Commented Mar 7, 2017 at 19:23

1 Answer 1


I figured it out.

If one presses the right arrow key just milliseconds before the dialog is displayed, then the default answer will not be selected and the blinking cursor will be placed after the default text.

You can perform this action in AppleScript like so:

-- Unselect the “default answer” in an input dialog:
tell application "System Events"
        key code 124 -- right arrow key
end tell

display dialog "Enter a keyword:" default answer "I do not want this text to be highlighted. "

In theory, the above solution should not work. In theory, the key press should commence and complete before the display dialog command initiates. But, this method does work, for whatever reason.

Note: This method will not work if you insert key code 124 before the very first dialog of your AppleScript file. In this case, my above code will fail to behave as desired and the default answer text will remain selected. (It may misleadingly appear to work correctly if you are simply running the AppleScript code from within Script Editor.app or Automator.app, but it will not work correctly if you run the .scpt file via Fast Scripts, osascript in Terminal.app, or any other method.)

However, if the display dialog in question is the second, third, or fiftieth dialog in an AppleScript file, my solution works correctly. Don't ask me why it won't work on the first dialog (because I don't know).

So, you have no choice but to rearrange the dialogs of the AppleScript file so that the first dialog does not need to have a default answer.

One workaround, if your initial dialog must have a default answer that is unselected, is to insert a dialog that automatically proceeds after a brief amount of time has elapsed. This dialog should be inserted immediately before the above tell block. It's not an elegant solution, but here is some code that will work:

display alert "Please wait..." message "..." buttons ("") giving up after 1
-- I think that "1" is the minimum for "giving up after." I tried "0.5" and the dialog completely stalled.

As long as it does not precede the initial dialog of a script, I have personally found my method to be reliable; it works 100% of the time on my computer.

  • While you may have found it to be reliable, I haven't. It worked once in ten times and besides that it is not a programmatically correct method because the key code event should actually finish before the display dialog. It will probably vary on each system tested and IMO it's a fluke its reliable for you. Additionally, reliable is when it works every time for anyone who tries it. Commented Mar 7, 2017 at 21:38
  • @user3439894 I forgot to mention an important caveat. Please see my updated answer. Is my method reliable on your system, when the display dialog in question is not the initial dialog of an AppleScript (and when you are actually running the .scpt file outside of an environment like Script Editor.app or Automator.app)? Commented Mar 7, 2017 at 22:45
  • Okay, only when run as a stand-alone app does it appears to be reliable. Obviously I have not done extensive testing but it certainly was quite different run as a compiled app vs. run within Script Editor. If I had a real need, I don't right now, I'd probably see if a dialog could be done in Cocoa-AppleScript to not have the default answer selected. Nice workaround though. I'll give it a +1 for ingenuity. Commented Mar 7, 2017 at 23:04
  • @user3439894 Thank you. It is not as good as a user3439894 answer, but it beats the other answers :). Just to be clear, my code does not only work reliably when it's saved as a standalone .app file. It also works reliably as a .scpt file if that .scpt file is triggered by FastScripts.app or in Terminal.app via osascript. Commented Mar 8, 2017 at 1:44
  • When I said "Okay, only when run as a stand-alone app does it appears to be reliable." understand that was meant as a comparison between the .app and run in Script Editor as that is all I had tested. It's nice to know it works in other scenarios too. Do not sell yourself short, it's definitely a good answer under the circumstances! :) Commented Mar 8, 2017 at 1:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .