This is outside the scope of this forum, but …
My understanding is that you never want certain keystrokes to trigger changes to media item properties. If so, why don't you just change or delete the keyboard shortcuts for the relevant commands in Reaper?
(For those who don't know Reaper, it's extremely customizable. If I were faced with a problem like this, I would attempt to fix it within Reaper before attempting anything complicated in KM.)
This post has been up for over a year and I just now noiced it. I have another idea. I use it to "intercept" the keystrokes in a Promt-With-List widow that I put up with KBM. It only works for the FIRST keystroke when that window goes up.
Before going into too much detail I need to ask, @mz94, Michelle, is this still a problem for you? And in your original problem, do you need to always, always, always, capture/intercept the problematic keystrokes, or only when the Media Item Properties window first appears?
I described my method originally in MACRO: “Follow Menu Choice with Return” (v0.5).
Briefly, before putting up the Prompt With List, I activate a dedicated KBM Macro Group for one keystroke. I your case, Michelle, you would have that triggered by the appearance of the Media Item Properties. At this point, with Media Item Properties frontmost, your very next keystroke, and that keystroke only, will be available to trigger macros in that dedicated macro group.
In that group, you can have multiple macros. You can have one macro for each keystroke that you want to intercept, each triggered by one key, or one macro that has numerous triiggers. (I chose the one-macro route because I wanted them all to do the same thing when triggered and editing one macro is easier than doing the same edit to 30 or more macros.)
In the "intercepting" macro(s) you can do a lot of things. KBM has caught the trigger before it got to the app (the Prompt-With-List window). I can now send the app whatever I want. In my example above (v0.5), what gets sent is the value of the trigger followed by a Return character. My own usage has evolved to where I first check if the trigger is capitalized or not, so I can send out different strings in either case (I haven't published that version yet).
In your case, when the Media Item Properties window first appears, there are a bunch of keystrokes you don't want it to get (and you want everything else to behave as expected). Activate your dedicated MIPWindowKeystrokeCatcher group. Inside that group, have a macro (or a bunch) that is triggered by those pesky keystrokes that will do unwanted stuff if they get to the MIP window, and have those keystrokes, and those only, do something like (as above) put a rectanguar highlight around the MIP window for a second, or whatever. Those keystrokes will be gone, gobbled up by KBM's trigger catcher. All non-trigger keystrokes will be passed along, to the MIP window if it can handle them, the main app, or whatever. Non-triggering keystrokes are not gobbled up, they get passed along.
This method only works to catch the first keystroke after the MIP window appers, but I suspect that that is the situation that is the real problem.
I hope this helps.
Before going into too much detail I need to ask, @mz94, Michelle, is this still a problem for you?
I believe, based on the solutions suggested thus far, I have thought of a sufficient solution: rather than highlighting the edge or drawing something over the MIP window when the MIP window is focused, I would rather somehow mask or add a colored/shaded window over all the other windows.
Basically, the problem stems from the use of an ultrawide monitor and/or multiple screens, always keeping the MIP window open (so, as I'm editing media items, i can quickly glance at certain properties in the MIP window as needed), and my focus (what i'm actually looking at) being on the main edit window (or some other window) when the keyboard focus/frontmost window is actually the MIP window.
So rather than highlighting or drawing a box around (or otherwise visually modifying) a window that i'm not looking at when this problem typically occurs, and which may even be on a different screen when it is the frontmost window, it would make more sense to partially obfuscate other windows (e.g. draw a semi-transparent colored highlight over them) whenever the MIP window becomes focused/frontmost.
That way, no matter which other window I may be looking at and think is the focused window at the time I'm about to press any problematic keystrokes, i'll have a clear visual indication over/around that window, indicating that, in fact, it's the MIP window that's currently focused.
And in your original problem, do you need to always, always, always, capture/intercept the problematic keystrokes, or only when the Media Item Properties window first appears?
Initially, I was thinking I would need to capture them anytime the MIP window is focused. But with the solution i described above, i think i should be able to prevent myself from making mistakes and changing things in the MIP window when I think another window has keyboard focus.
the part where i got stuck thinking this was a complicated problem to solve is, sometimes, i actually do want various keystrokes to work when the MIP window is focused (i.e. when i've intentionally focused it to edit properties of selected media item(s)), but don't want them to do anything in it when it is unintentionally focused, which is hard to notice when it's on another screen, or far off to the side of what i'm actually looking at.
But by modifying the appearance of the rest of the screen/app windows (for any/all displays & open windows), it'd be practically impossible not to notice it anytime I unintentionally have the MIP window focused/frontmost.
and, now that i'm thinking about it, this would probably be a good thing for me to implement as a system-wide solution, since there have occasionally (or quite often, depending on how busy i am) been times where i accidentally typed some text into the wrong window, or triggered macros in the wrong app/window, because i couldn't easily notice that the app/window i thought i had focused at the time actually wasn't frontmost.
so, i think the ideal solution for me would be having a global macro that simply lightly shades all other windows, or all areas of all connected displays, except for the currently focused app's frontmost window.
So now, i just need to figure out the most efficient way to do this without stealing focus from the frontmost app/window.
Have you considered using Semaphore Actions to capture and queue key presses?
While I don't have immediate ideas for how to accomplish this, short of having the computer track your eye movements and give the window that you are looking at the focus, I do note that many apps these days have a "focus" mode that attempts to minimize distractions. Amazing Marvin, for instance, is specifically designed for neurodivergent people to be able to focus.
I believe that if you can make this work, it could be a boon to anyone whose mind all too often gets ahead of their fingers.
As a brief outline, I would try to create a simple app or instance of a small graphic app, that could fill the screen, and fill the extended desktop of multiple screens, with a transparent window. Just make something that covers everything that you can still see through. I don't know how to do that. It would also have to accept mouse clicks. Then for every window change (except going to that overlay window), the instant the focus changes to your target window you would bring the overllay window to the front and then bring the target window to the front. Thus only the target window would be in front of the overlay.
When you click on a different window, it's under the overlay, so the overlay would have to capture your mouse click (or KBM captures your mouse click, depending on how it's implemented) and pass it on to the OS to activate that new target window. When that window activates, the overlay gets moved to tthe front and the new target window gets moved in front of that.
As I said, this kind of distaction reducito, background softening, foreground emphasizing system could be hugely useful for a lot of people. Maybe someone has already done something like it.
Just ideas...
Just a brainstorm.