Buttons: Simulating the activated state and/or procedurally "clicking the button"


I have a dialog form with two buttons, “Cancel” & “OK”.

I want to procedurally “click” either button, but I’ll concentrate on the “OK” button.

I’d prefer to use the Return key to activate the OK button. That is a hotkey assignment. When, in calling the dialog window, I use the code:

definehotkeys “window”, “RETURN”, {message “Hello World!”}

in the case of Dialog.Initialize, and then press the return button in the subsequent dialog, the message window appears.

Under the same circumstance, when I use the code:

definehotkeys “window”, “RETURN”, {closedialogwindow}

the dialog window closes, but the “OK” button doesn’t highlight to indicate it has been pressed.

Is there a procedural way to either highlight the activated button or “click” it?

Any help is appreciated as I have scoured the documentation without success.



There is no way to highlight the button (any button).

It sounds like you are using rundialog to manage your dialogs, which is good. In that case, the OK button will automatically be triggered by the Return key – if the OK button has been set as the default button. Also, if your dialog contains Text Editor objects, they must be set up so that the Return key terminates editing. Also, all buttons in a dialog should contain this code:

resume {}

In the rundialog documentation you should look at the section about Multiple OK buttons.

You don’t want to use the definehotkeys statement with the return key. The rundialog statement already handles that for you.

You don’t want to directly call closedialogwindow when you are using the rundialog statement. That bypasses all of the close dialog code in rundialog’s code.


Thank you, Jim! You are correct in that I am using the rundialog command. I included the resume command in each button. However, I missed the “default button” setting when creating the “OK” button on the form.

Now, the only problem is that “Enter” is the keystroke that triggers the default “OK” button, whereas I would like it to be the “Return” keystroke. On my laptop and my Apple wireless keyboards, the Enter keystroke is accomplished via Fn-Return. It’s easier to hit the Return keystroke.

How do I make that happen?

Also, the Esc keystroke will close the dialog, but it doesn’t highlight the “Cancel” button (whereas the “Enter” keystroke does highlight the “OK” button). Indeed, if I place a message box command in the “Cancel” button’s procedure pane, then mouse-clicking on that button activates the “Cancel” button, whereas the “Esc” keystroke does not exhibit that behavior. Is there a way to activate the “Cancel” button (so that it highlights to indicate it was chosen) with a hotkey, the “Esc” key or some other technique?


In my tests if the text editor objects have the Termination Keys -> Return checkbox enabled, the dialog does close when the Return key is pressed, as well as the Enter key.

And let me repeat, there is no way in Panorama to highlight any button under program control. When the OK button highlight’s, that’s actually because Apple’s code does that, not Panorama’s code.


By the way, now that you’ve brought it up, it would certainly be a nice touch if it were possible to highlight the buttons as you are suggesting. There are a lot of much higher priority projects on the to-do list, but I’ve added it to the “someday this would be nice” list.


Jim, I didn’t have any text editor objects in my dialog, only an OK and Cancel button, as I am testing the concept. Thanks for your explanation and for considering the highlighting concept.

I have two questions:

  1. Shouldn’t the Return keystroke work without having to have a text editor object in the dialog box? What if only an image were in the dialog box … would that allow the Return key to be used?

  2. Regarding the Cancel button: The Cancel button doesn’t appear to be activated when using the Esc key. In that respect, it’s behavior is different than the OK button, which visibly activates (the blue color becomes darker) when the Enter key (or in appropriate setups, the Return key) is pressed.

As an example, when the program PathFinder quits, it displays a confirmation dialog. Pressing the Esc key closes the dialog (without quitting PathFinder), but before the dialog closes the Cancel button turns blue, providing feedback to the user. In Panorama the alertmodal command functions this way also (the Cancel button turns blue when the Esc key is pressed, prior to the dialog closing). This doesn’t happen with the rundialog command, at least not with the simple setup that I am using.

Using the rundialog command, can the Cancel key be made to visibly activate using a keystroke? If not, would it be possible to add that feature so that the behavior of the UI is consistent?



  1. Looks like there is a bug, so I’ve filed that separately.

I already said that would be a nice touch – go ahead and take the win.

Perhaps you are advocating that this should be moved to the front of the to-do list. That’s not going to happen. This is not a massive project but I don’t think it is trivial either. I see projects like Panorama Server, crosstabs, iPad version, etc. as way more important.

the alertmodal command functions this way
doesn’t happen with the rundialog command

If you are looking for an explanation of the difference, it happens with built-in Apple dialogs. You’ll also see it happens with Open/Save, Print, etc, which are all built-in Apple dialogs. These are dialogs/alerts that were built with Apple’s Interface Builder.

When a dialog is displayed with rundialog, it is created from a Panorama form. It isn’t really a “dialog” as far as Apple’s code is concerned, so it doesn’t automatically get every feature that Apple builds into it’s own code. But – it is easily customizable by you, without having to learn XCode and Objective-C or Swift. I’ve tried to make these custom “faux” dialogs as close to real Apple dialogs as possible, but as you have pointed out here, the simulation isn’t quite 100% perfect, at least for now.



First, let me apologize as it appears my comments came across in a way I had not intended. Right now, I’m just trying to get my head around Pano X, in the time I have to devote to it.

I was confused by the disparity in button behavior between the alertmodal & rundialog commands. Frankly, I hadn’t noticed the difference in the native behavior of Apple’s Cancel button which you have pointed out, despite having used Apple computers for over two decades. Curious how the mind works and what we choose to observe or ignore. Oh, well.

You’ve provided an explanation which has been useful to me. Thank you.



To be honest, I had never really noticed this highlighting behavior of Apple’s standard dialogs before, so thanks for pointing it out. I think we are now on the same page :slight_smile:


Now from the “let’s see if can be done” department. I came up with a brute force work-around for the escape key not highlighting the Cancel button when closing the dialog window. My approach has the Cancel button named cancelButton and the OK button named okButton so that I can use the changeobject statement to do the highlighting. The actual highlight is accomplished by turning the default option temporarily on for the Cancel button and off for the OK button and then both back again.

The mechanics involve trapping the escape character and executing the changeobject code and then repeating the loop so it finishes normally. There are also traps to adjust things if the escape key was already the last key pressed when the dialog was opened.

This example assumes the form used for the dialog is named Dialog containing the two buttons mentioned above and properly named.

local escapeCheck, escapeTrap, escapeState
    rundialog {Form=Dialog Sheet=TRUE Height=120 Width=400}
    If (asc(info("keyboard"))=27 and escapeCheck ≠ 27) or (escapeState=1
        and info("trigger")="Dialog.Cancel")
        changeobject "cancelButton",
        changeobject "okButton",
        changeobject "cancelButton",
        changeobject "okButton",
    repeatloopif escapeTrap=1
    stoploopif info("trigger")="Dialog.Close"

Regarding the Return and Enter key not activating a default button if there is no Text Editor on the form, experimenting on my iMac with a Macally extended keyboard showed that only a Command-Enter or a Control-Enter combination will trigger the default button. No other key combination with the Enter or Return keys are recognized.



This works like the proverbial charm! Now to attempt to integrate it with my workflow … and study how you did this.

Thank you for your generosity in sharing!