Load Button at Specific Screen Location

I want to have a macro that runs a few actions and at the end loads a button on the screen (I don't think KM has this, besides the Prompt User Input?).

I would like to have that button (or window) snap to the top right corner of the screen.

I know that KM saves the position of the last window, but is it possible to make this exclusive to this macro, even if the last window was in the middle of the screen?

1 Like

I found this other thread. I will read it and see if I can make it work:

Yes. KM10 has a new Action Set Next Engine Window Position which can place the Prompt in the top right of screen.

Click to Show Image of Macro

EXAMPLE Set Prompt Window Position to top right corner.kmmacros (2.7 KB)

But bear in mind that the next Prompt (in any Macro) will also be initially placed at this position (as the Prompt remembers its last position). So, you might want to do something like the below in other Macros.

(I mostly like the Prompt to pop up in the middle of screen so I tend to put one of these "centre windows" Actions in front of each Prompt anyway.)

Click to Show Image of Macro

EXAMPLE Centre Prompt WIndow.kmmacros (2.9 KB)

1 Like

What do you mean by this?

Display a button on the sceen?

1 Like

The same way you can have the Prompt for User Input, but just a button.

Right now that window takes too much space with the KM logo and all the empty space when you delete all the extra text. If I just want the OK and the Cancel buttons, it would be great if the window only took that space used by the buttons. Right now this is all the space it takes:

image

I was thinking something like this:
image

Yes, nice, but that can't be done unless you made your own custom HTML prompt.

1 Like

Or AppleScript if it's literally two buttons?

https://alvinalexander.com/blog/post/mac-os-x/applescript-customizing-dialog-boxes/

2 Likes

Or you could use a Palette... after all, Palettes are for clicking on, to do things.

2 Likes

Would a pallete stay onscreen while you're clicking away doing other things before you want to hit the button? If so, that's a neat idea.

Yes, it could stay onscreen as long as needed (you would have a Show Macro Group Action in your main Macro set to show palette). Probably good idea to have the Palette Group set to "show for one action" which means it would close after whatever of the two "buttons" is pressed, like a User Prompt. And being a Palette, it will remember its position on screen. Or there is a Plugin by @ComplexPoint to position a Palette wherever you want,

Screen Recording 2022-11-30 at 22.34.57-Animated GIF

2 Likes

AppleScript's Display Dialog command can have three buttons these days:

Two buttons:

set ddResult to button returned of (display dialog "Pick One..." buttons {"Drive Me Nuts!", "Cancel"} default button "Drive Me Nuts!")

Three buttons:

set ddResult to button returned of (display dialog "Pick One..." buttons {"Drive Me Nuts!", "Cancel", "OK"} default button "Drive Me Nuts!")

display dialog

display dialog (verb) Display a dialog box, optionally requesting user input (from the User Interaction suite, defined in StandardAdditions.osax)

Function syntax:

set theResult to display dialog text ¬
     default answer text ¬
     hidden answer boolean ¬
     buttons list of text ¬
     default button text or integer ¬
     cancel button text or integer ¬
     with title text ¬
     with icon text or integer ¬
     with icon with icon ¬
     with icon file ¬
     giving up after integer
result

dialog reply: a record containing the button clicked and text entered (if any)

Display dialog is reasonably versatile for an old fashioned modal dialog.

Back in the day there was an Osax called Dialog Director that could do unbelievable things.

These days AppleScriptObjC can do almost unbelievable things, but it's not exactly user friendly.

That said – Shane Stanley wrote a free AppleScript library called "Dialog Toolkit Plus" that makes dialog scripting a bit more palatable. Here's a very simple example of what's possible:

image

Keyboard Maestro can do this sort of thing natively, so there's not much reason to turn to AppleScriptObjC – particularly in view of KM's Custom HTML Prompt action which is wonderfully flexible and uses industry standard code.

3 Likes