One more question. This macro seems to only be able to search the list of windows in the frontmost application. Most of the time this will be fine but, sometimes, I need to search all open windows from all open applications. Is that possible using this approach?
Hey @Footbaggin,
You'd have to iterate through all the apps and get all of their windows – then you'd have to be able to identify what window name belonged to what app.
This can be done with Keyboard Maestro, but I find it easier to do with AppleScript and System Events.
This script will produce a flat list of window names prefaced by their app-name – run it in the Script Editor.app to see how it works.
Use with an Execute an AppleScript action.
From there you can use the Prompt with List – massage the returned item a bit – and use a Bring a Window to the Front action to activate your chosen window.
-Chris
------------------------------------------------------------
# Auth: Christopher Stone
# dCre: 2019/09/04 16:36
# dMod: 2019/09/04 17:07
# Appl: System Events
# Task: List the Name and Process of Every Window of Normal Apps.
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @System_Events, @List, @Name, @Process, @Windows, @Normal, @Apps
------------------------------------------------------------
set windowList to {}
set flatWindowList to {}
tell application "System Events"
set processList to application processes whose background only is false
set processNameList to name of application processes whose background only is false
repeat with theProcess in processList
set end of windowList to name of windows of theProcess
end repeat
end tell
set processNameIndex to 0
repeat with ndx1 in windowList
set processNameIndex to processNameIndex + 1
repeat with ndx2 in (contents of ndx1)
set end of flatWindowList to ((item processNameIndex of processNameList) & " » " & (contents of ndx2))
end repeat
end repeat
set AppleScript's text item delimiters to linefeed
return flatWindowList as text
------------------------------------------------------------
1 Like
So, I'm using the Prompt With List method and it works really well but with a key flaw. It turns out that in my workflow I am commonly combining windows into a single tabbed window. The issue there is that KM can only see the name of the currently selected tab. That said, all of the window names are viewable in an application submenu. So, is it possible to use Prompt With List to %MenuName%All% or some similar token? If so, how would I specify the submenu? Thank you so much for all the help!!!
I tried using apple script to get the names of all the menu items. It works but it stores them as a string in the KM variable. How can I tell apple script to parse the items out into individual items?
Add these commands to the end of your AppleScript:
set AppleScript's text item delimiters to linefeed
return windowList as text
1 Like
Works perfectly! Thank you so much!
Working version for future searchers:
Thanks for sharing. Would you mind also uploading the macro file?
1 Like
Absolutely!
SEARCH AND FOCUS WINDOW - SEARCH FOR OPEN BIN 3.0 MENU VERSION.kmmacros (7.0 KB)
Macro-Image
However, I'm in the process of improving it. I've widened the scope to include all menus in the application via AppleScript. It creates a list of every menu item in the application as desired but I don't know how to tell it which menu to find the user-selected item is in.
Is there any way to Select Menu > Menu Title = "Any" > Menu Item %userSelectedWindow%?
I have accomplished searching all menus using apple script. Once I've figured out how to incorporate sub-menus I will post.
Did you ever manage it? There have been a few requests about this kind of thing lately.
Like what?
My memory isn't bad, but June is pushing it.
1 Like
Getting every menu item and every submenu item in an app via AppleScript tends to be pretty slow.
Using Google Chrome as my test app and running from Script Debugger 8.0.5 (8A61) on OSX 10.14.6.
tell application "System Events"
tell application process "Google Chrome"
tell menu bar 1
set menuRefList to entire contents
set menuRefListLength to length of menuRefList
end tell
end tell
end tell
On my old i7 MacBook Air it takes around 22 seconds to return a list of 9849 values.
Let's try a more modest app like TextEdit...
551 items in about 1.4 seconds.
Not bad, but then again those are pure AppleScript references and are not very useful without further processing.
More and more time gets added in.
Entire contents tends to be slow anyway, and one might actually get better speed by building a recursive routine to go through every menu and submenu.
The moral of this story is that I would never try to grab every menu item and submenu item from an app without a very good reason.
Might the solution be to perform the search when the app launches, and then reference the result later when trying to access menu items? As I type this, I'm fairly sure I saw someone do this to good effect. Posssssibly with Pro Tools. So much for my "good" memory.
That wouldn't be a bad solution if you didn't have to get changing values from dynamic menus.
Another possibility would be to run the menu-scraper routine manually at need.
1 Like
Then you have the added complication that some apps (I'm looking at you, Logic Pro!) don't refresh their menu item status until the menubar is clicked. When I need to test (and click, in this case) the status of a menu item in Logic, my workaround is:
You can also do that with AppleScript, so when you know a menu will be populated that way you can build it into the scraping script.
1 Like
Jeez. I'll be finding my phone in the fridge next.
1 Like