This is indeed what I use since I got this hint from my first related question.
This is something I need to check when I maybe have a little more time. It sounds and looks very interesting. Currently I am really happy with the solution I have gained thanks to your and other members help.
BTW: I forgot to mention that I also used KM for way more than three years before I stumbled over the awesome Palette feature through the great tutorials of @appleianer!
How about closing a palette whose names contains a certain term? I have a single macro that opens one of many palettes based on the front application, so the palette name varies. I'd like the macro to first check to see if one of its palettes is open, and if so, close it. The palette names all end with "(menu)"
I tried a bunch of stuff like this check for an open palette with a name containing the term:
tell application "System Events"
set theWindows to name of every window of process "Keyboard Maestro"
repeat with i from 1 to length of theWindows
set theWindow to item i of theWindows
if theWindow contains "(menu)" then
return theWindow
end if
end repeat
end tell
... but no dice because KM doesn't "see" palettes.
Since KM is handling the initial triggering of the macro, you could have it set the front application to a variable which is then passed to the AppleScript. So for example, if Safari is at the front, you could have KM pass the name of Safari's palette via a variable and then have the AppleScript read that variable to close said palette.
But.... this can likely be done natively with KM.
I have a similar macro that opens a palette based on the front application, and then hides said palette after I click an entry (or hit the ⎋ key, or 5 seconds of inactivity pass). You mentioned checking to see if a palette is open and then closing it... is there a reason you need to check first instead of just using the KM action Hide Macro Group?
Thanks @cdthomer - I'm not married to AppleScript here, but I'm still stuck on how to do it as you described with a variable and/or natively. The palette is determined with a Switch/Case action and a bunch of manual entries like this:
I made this a few years ago, and even though it's a little clunky, I've just added to it over the years by duplicating the group into a new "case" as needed for new apps.
Anyway, I don't know how to create a variable for the given macro group since it's set with a drop down list, and the ExecutingMacroGroup is the group the macro itself is in, not the macro group of the palette.
FWIW: This was a minor feature I wanted to add, but now I'm more curious than anything
So this is one way to pass the front app's name as a variable to AppleScript which can then use it to close the palette assuming the palette contains that app's name. I imagine since the palettes in question are specific to each app they should have some sort of naming convention that identifies them as such.
It works quite well for me in my limited testing but please let me know if it does or does not work for you!
----------------------------------------------------------
# Author: Chris Thomerson (@cdthomer)
#
# Current Version: 1.0 (Initial script)
# Version History: 1.0 (Initial script)
#
# Created: Saturday, January 29, 2022
# Modified: Saturday, January 29, 2022
# macOS: 11.6.3 (Big Sur)
# Tags: Keyboard Maestro, Palettes
#
# DISCLAIMER
# Permission to use, copy, modify, and/or distribute this
# software for any purpose with or without fee is hereby granted.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
# WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
# THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR
# CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
----------------------------------------------------------
### Requires Keyboard Maestro 8.0.3+ ###
set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
set frontApp to getvariable "local__frontApp" instance kmInst --gets variable from KM
end tell
tell application "System Events"
tell application process "Keyboard Maestro Engine"
--pauses until the front application's palette appears
repeat until (first window whose subrole is "AXSystemDialog" and title contains frontApp) exists
delay 0.1
end repeat
--simulates clicking the close button of said palette
click button 1 of (first window whose subrole is "AXSystemDialog" and title contains frontApp)
end tell
end tell
(first window whose subrole is "AXSystemDialog" and title contains frontApp)
Your code works great after a slight tweak to test if the palette is open:
tell application "Keyboard Maestro Engine"
set frontApp to getvariable "local__frontApp" instance kmInst --gets variable from KM
end tell
tell application "System Events"
tell application process "Keyboard Maestro Engine"
--pauses until the front application's palette appears
if (first window whose subrole is "AXSystemDialog" and title contains frontApp) exists then
--simulates clicking the close button of said palette
click button 1 of (first window whose subrole is "AXSystemDialog" and title contains frontApp)
end if
end tell
end tell
Thanks so much! This snippet will help me beyond this one use
Hey @cdthomer, is this still working for you? I thought I would check before I go diving in to see why I am having a problem with this:
(first window whose subrole is "AXSystemDialog" and title contains frontApp)
Error:
System Events got an error: Can’t get button 1 of window 1 of application process "Keyboard Maestro Engine" whose subrole = "AXSystemDialog" and title contains "Keyboard Maestro". Invalid index. (-1719).
Yes it is still working for me. However, AppleScript in general has become very buggy as of late. See my topic below for an example of the issues I’ve had. So it doesn’t surprise me, unfortunately, that you are having issues.
I started to debug by inserting the always-helpful Variable Inspector Prompt action into the macro as various points.. As I moved the action down through the macro to isolate the action that was erroring - surprise - no error. Now it's working fine for the moment. Weird.
