Activate Window Under Mouse Cursor Without Clicking


Is it possible to activate an application window that is currently under the mouse cursor without clicking it?

The reason is that I use a software where tools are activate per window. In certain situation the draw tool might be selected in a window that is currently inactive, and when re-activating that window with a mouse click, it would also draw an event in the window depending on where the mouse cursor is. Only way to prevent it is to click the window title bar.

What I would ideally want to do is to not have to first click the window title bar to activate i, and then select a tool. Instead, I'd like to use a macro that activates the window under the mouse cursor (without clicking) and selecting the tool for me.

Hey Andreas,

Unfortunately Keyboard Maestro cannot detect what window is underneath the cursor.


Thanks for response!

Ok, is it possible to detect which screen the mouse cursor is currently on in a dual-monitor setup?

Hey Andreas,

Perhaps I spoke too soon.

Keyboard Maestro + macOS cannot directly detect what window is under the cursor, but you can detect the cursor location and you should be able to detect your window locations.

What app are you working with?


MOUSEX function
MOUSEY function
WindowFrame token


1 Like

That is some excellent logical thinking. Thanks, I'll look into that.

I'm working in Nuendo.

Hey Andreas,

I recommend downloading and using Script Debugger for all things AppleScript.

The demo reverts a freeware "lite" version after the trial period and still totally destroys Apple's Script Editor.

Run this AppleScript while Nuendo is running, and examine the results.

tell application "System Events"
   tell application process "Nuendo"
      return properties of every window
   end tell
end tell


I'm bumping this. Unfortunately I'm loaded with work, so I'll have to outsource this, but I need this done, it annoys the hell out of me every single second of my working day.

Is there anyone willing to help out for a fee?


Start by complaining to the app Devs -- clicking on an inactive window should only activate it, not do something in it (the clue's in the word "inactive" :wink: ). Sounds like a bad port of Windows software, but I doubt they'll do anything about it.

So something that'll activate the window the pointer is over... That'll depend on Nuendo returning a sensible result when you ask about its windows. Can you try the following (you'll need to set an hotkey trigger) with a Nuendo frontmost and some windows open and let us know the resulting text and how many windows there were?

Window test.kmmacros (2.0 KB)

Hey Guys,

Take note of the fact that these tokens only work on a per application basis, so the Nuendo app will have to be the active app in order for them to work.

Hey Andreas,

Please be more specific about the mechanics of your process.

  • How many monitors are you working with?
  • Is Nuendo the active application when you're wanting to activate its window?
    • Or is it an inactive app?
      • On the same screen you're currently working in – or not?



Fortunately, if we're going back to the OP problem, "put pointer over window and run macro to activate it" means we can start the macro with "activate Nuendo" to be sure that it is the active app.


Thanks for looking into this @Nige_S and @ccstone. Here's a more detailed explanation.

Nuendo consist of several independent framed window's containing titles. These can be recognized, and I'm using the "Front Window of Front Application" condition to do several things, like choosing the proper tools, etc. So all application window's can be recognized by it's title.

I'm attaching a screenshot of the layout of the workspace. Here's some details:

  • Nuendo will always be the activate app.

  • In Nuendo, there will be active or inactive application window's on different monitors.

  • I'm always using two monitors. They are always set up in the same way, but because I have workstations in several places around (where I have different equipment) the resolution of the screens are not always the same. I can set up the different workspaces so that the window in question will always have the same placement related to the top-left corner if that helps window's recognition.

  • The main window is called the "Project Window" and the title of that window always has the name "Nuendo Project - [project name]". I'm using the "Title Contains" condition to identify that window, and that works without issues.

  • The other window that I'm using is the Key Editor. That always has the name "Key Editor: [track name]". I'm using the same Title Contains condition to identify that.

More detailed explanation follow:

Nuendo has a combination of two extremely annoying "features".

  1. The tools (Pen, Arrow tool, Resize, etc) are not synced between the Project Window and the Key Editor. This means, that I can have the pen enabled in one of the window's and the Arrow Tool in the other. It also means that if I edit something with the pen in the first window and switch to the other window, the pen tool will still be selected in the first window, meaning that if I go back to the first window, it will default back to the pen. If the pen is selected, then it will do edits, if I don't click the title bar.

I've tried fixing this in the following way: When the keyboard shortcut for a tool is pressed in Window 1, it will quickly switch to Window 2 as well and select the same tool there, and then switch back. That works "ok", except that I can't type anything in Window 1, since the tools are selected with shortcuts P and T. So I've given up on that for now.

  1. For this sake, we can keep to the two most commonly used tools: Pen and Arrow tools. The Pen tool is selected with key "P", the arrow with key "T" in the Project Window, then Shift + P and Shift + T in the Key Editor. The different shortcuts between window's have been solved with KM just sending the proper shortcut in both window's based on the window title (so even if I press P in the Key Editor, KM will send Shift + P).

In other DAWs (Digital Audio Workstation software), if I were to just hoover the mouse over one window and press "P", that would selected the pen tool of that window. That is not the case in Nuendo. The Window needs to be active for the shortcut to work.

The combination of these two "features" mean that I constantly end up – when working in a high pace – having the wrong tool selected. I move the pointer over a window, press the key for the shortcut, then press the mouse, ending up having a different tool than I was expecting. The only way is for me to first move the mouse up to the title bar, click that, then select the tool using the shortcut, and start working.

Since I use these shortcuts about a thousand times a day, this is slowing me down and annoying me significantly as you might understand.

A suggested solution would be: When I press "P" or "T", Keyboard Maestro would recognize which window is under the mouse cursor, then activate that window, without me having to press the title bar, then sending the shortcut for the tool to that window.

Hope this clarifies things.


Screenshot 2022-11-14 at 11.25.24

What do you get when you run @Nige_S' macro in post #8?

As you've already seen, a single-key hotkey trigger like "P" or "T" is generally A Bad Idea -- it's difficult, if not impossible, to replicate an app's "is this typed text or a shortcut?" decision-making process.

So the following uses both ⌃P and ⌃T as triggers. It's set to work with TextEdit, and to exit for safety's sake if TextEdit isn't frontmost -- you can easily change that, either changing the detected app to Nuendo or deleting the first "If" action entirely, once you've seen how it works.

Launch TextEdit, create a bunch of new documents, scatter the windows around your screen. Put the pointer over any of them and hit ⌃P or ⌃T and the macro will make that window active and type either "p" or "t" into it. You can easily add more triggers for different characters and add to the "Switch/Case" action so the correct key is pressed.

Actvate Window and Type a Key.kmmacros (9.8 KB)


There's nothing tricksie there, but if you've any questions about how it does what it does -- just ask!

You should probably look to using menu items rather than keystrokes to activate the tools, if only to avoid the situation where the pointer is over a window that already has the insertion point in a text field. Running the macro in that case would bring the window to the front and type into the field -- probably not want you want.

@Nige_S I've been trying out your solution now, and it works perfectly, I'm very grateful for the help! I assigned the shortcuts to F1-F4 instead to avoid any conflicts.

Thank you.