You may be aware of a longstanding issue with Chromium browsers whereby Keyboard Maestro can't find an image in the front window. There's a workaround that involves manually calculating the front window size and position, then searching within those bounds. Seems bizarre to me that KM has a problem with certain app types, but there you go.
Well, now this seems also to be the case when the front window is a plugin UI in Logic Pro. I'm not sure if it's something to do with having upgraded to Ventura or updated to the latest version of Logic (10.7.6), but it's currently broken. Clicking in Logic's main interface works just fine.
If KM can calculate the front window size and position using discrete actions, what's the barrier when using the Front Window option in, for example a Click at Found Image action? Surely it works the same way..?
I'm still none-the-wiser about the Logic plugin windows. Odd, isn't it.
As far as I can see, Keyboard Maestro can get the image of a Google Chrome window without problems unless it is in Incognito mode. In that mode, Chrome presumably actively blocks screen capture. Chrome’s actions are pointless in this case since you can capture the area of the window with:
The same can happen in Safari if you are playing some copy-protected media.
Yes, this is frequently the case with Chrome as well, but in that case Keyboard Maestro might not be able to determine the location of the window.
Note that these are all different:
Screen capturing a specific window.
Determining the location of a specific window.
Screen capturing the area on the screen occupied by a specific window (requires being able to determine the location).
Other than that explicit case, each of them are different and might fail for independent system/application reasons.
Still no closer to figuring out why Logic is misbehaving.
@peternlewis, how does the front window function work for found images? Is it not the same as taking the front window size/position and then restricting a search of the screen to those bounds? This method, when performed explicitly with KM actions works just fine, so I'm not sure why there's an issue with the built-in front window option of found image actions.
When taking an image of a window (either for Screen Capture or Find Image on Screen), the window image is captured directly. That is, the system is asked for the image of the specified window, not for the image within the area on the screen that the window occupies.
For example, these two actions:
and
are not equivalent. They ask the system for different things and will give different results if the second window is behind the front window - the former will capture the entire window, where the latter will capture parts of the front window and the unoccluded part of the specified window.
If KM can see the window it ought to be able to operate on it.
Make sure you don't have any invisible characters in the window title.
Where are you getting that window list?
If that's my tool for System Events then that's most likely the problem – that tool specifically reveals windows System Events can see – not windows KM can see.
Sounds like it isn't the detection/targeting that's the problem, but the "promotion" of the window to frontmost. Is the window listed in the "Windows" menu? Could you perhaps use something like
to get round the problem (having the menu flash up isn't as smooth, but better than nothing...)?
Actually ‘doing the thing’ isn’t really the issue. Simulating the cycle windows hotkey until %FrontWindowName% matches works fine. It's more that I'm perplexed as to why Logic's plugin windows would stop playing ball all of a sudden.
What if your window name is “Guitar”, but your Action text is “Guitar ” with a space?
See what I mean?
When you test for things like the FrontWindowName token it's a good idea to use quotes of some kind around the token, so you can see any oddball spaces:
I'm using guillemets, because they're not likely going to be in any text I test – but you could use quotes or bullets or whatever you like.
Keep in mind too that the Display-Text-in-a-Window action TRIMS text, and the quotes prevent that from happening.
I can't tell you how much hair I pulled out, before I discovered that little issue.
It's also a good idea to copy the text result and paste into BBEdit or another text editor that can show invisible characters.
Change this script to appropriately reflect your app and window name and run it from Script Debugger:
tell application "System Events"
tell application process "BBEdit"
set frontmost to true
tell window "untitled worksheet 74"
perform action "AXRaise"
end tell
end tell
end tell
Let me know if it brings the window to the front or not.
