I have a command that I use in one of my applications that uses SHIFT-M
Is there anyway to have this hotkey trigger be disabled when I'm typing text in an active field within the application where SHIFT-M will be ignored as a hot-key trigger and instead provide only a capital-"M" ? I have searched the forum and I think I mostly found in past posts that this was not possible with "Single key hot keys"-- but since I'm using the modifier of SHIFT, I'm wondering if there is a way to have KM ignore SHIFT-M when actively typing in a field. Thank you very much for any advice.
Yes you can search for the window that is in front and then if that window is seen you can have it ignor that command. I do this often in various apps.
That works if the front window is nothing but a text input field, but I don't see how it would work if you were (for example) in a Safari text input box here on the forums. Am I missing something?
Assuming I'm not, there is no official way (that I've ever seen) to determine that the cursor is in a text input field. You can try various things to work around that, but I don't think I've seen a 100% foolproof solution here.
For instance, you can see if Edit > Paste and Match Style is enabled, which will generally only be true if you're in a text field. But of course, that relies on having some text on the clipboard in the first place, and some weird app may have it enabled all the time.
You can try to do a screen capture around the cursor location and see if you can match the I-beam cursor, but that thing is basically impossible for Keyboard Maestro to see, given how small it is and how similar it is to other onscreen shapes.
If this is designed to cover only one specific app, you might look at that app's menus; maybe it does something unique when you're in a text input field and you could use that as an identifier.
Regardless of the method you find (if you can find one), you'd add it as a condition in your existing Shift-M macro: If (text field check) is true then send keystroke M, otherwise do the normal thing.
None that I have seen either and windows that don't show names don't work with this, which is unfortunate.
This is great advice. I use this frequently as well for several macros that check for the state of things like this that really don't relate to the function I am trying to do but they get greyed out. Like playing in a DAW menu items change so that is how I check that it is playing rather than looking for a screenshot which is a much better approach.
Then try something new If you really need it and are not exclusively fixated on KM, there are other apps that do this perfectly. For example BTT.
Place the cursor in the desired field and BTT will show you the name of the field. Then you can set a condition that only affects this field (or several).
This is an old old item on my wish list. in certain apps, many macros could just have normal (unmodified) key triggers but for a small minority of time where the keys are actually used for typing.
One imperfect solution is to check for paste item active in the app's menus. Here's an applescript snippet that checked the Paste menu item in the Finder.
-- to know if editing, determine if “Paste” menu item is enabled
tell application "System Events"
tell menu bar of process "Finder"
tell menu "Edit"
set pasteItemList to first menu item whose name is "Paste"
set pasteItem to item 1 of pasteItemList -- i don't get why this is a list, but..
set editFlag to value of attribute "AXEnabled" of pasteItem
end tell
end tell
end tell
this is just a snippet, not a full solution. you'd change "Finder" to whatever app you're working with. it sets the applescript variable, editflag which you can use in your logic determining how the macro behaves.
tell application "System Events"
set theApp to first application process whose frontmost is true
tell theApp
set theRole to role of (value of attribute "AXFocusedUIElement")
if theRole is "AXTextField" or theRole is "AXTextArea" then
return true
else
return false
end if
end tell
end tell
Save the "If" action as a favourite, then we can either set a variable for later use or include our "insertion point is/is not in a text field" actions in the execute/otherwise blocks.
The above returns true for both text fields (eg Safari address bar) and text areas (eg Script Editor's document body).
It still isn't a "perfect" solution. It works for FileMaker Pro's "Search" UI element, for example, but will error if the insertion point is in a FileMaker record field (the same is probably true for BTT, since there's no "AXFocusedElement" returned). And I'm pretty sure it'll fail in Electron apps, for the same reason.
But another arrow for quiver, alongside menu item detection etc.
That's pretty handy. One of these days I need to really dive into BTT. I still have so much to learn in Keyboard Maestro still I find it hard to find the time to go to other solutions. I went into Keyboard Maestro kicking and screaming after investing so much time into QuicKeys and that lost support.
These are great ideas and I am excited to test them out and see how well they work in Pro Tools and other apps. It gets old having to constantly add a new window all the time and several of them don't even have window titles so it doesn't work for the text field. Thank you for the great ideas in this thread and hopefully better solutions or more solution options.
I can tell you that I have never been confronted with an app where BTT could not recognize a field. I don't understand any of this, but does it help if you can also set a “focused_element_subrole”?
The combination is very helpful for accurate differentiation.
I know that some apps do not disclose fields voluntarily. For such cases, BTT can be set to actively ask. So far this has always worked.
The good thing is that both apps can be used together without any problems. They complement each other perfectly. It is not necessary to master KM completely in order to use BTT. Quite the opposite.
I'll search the forum but just out of curiousty and related to this thread. I don't totally understand are you able to use feedback from BTT to tell Keyboard Maestro that you are in a text field? If so that is awesome and just want I need. I don't want to have to set exceptions for single keyboard shortcuts in apps and have that always work. That image you showed is new to me and I am guessing that there is away for BTT to do this and then pass on a True or False statement to Keyboard Maestro to know if it is in a text field or not. I of course ideally would love to just keep everything in Keyboard Maestro if at all possible and only get one app approved to install on work computer or other computers that I do work at that are not mine.
If you only want to use KM, then I would follow the path that @Nige_S has pointed out.
But honestly, is it really necessary for an app to decide for you which field the cursor is in? If you are willing to decide that yourself, a short/long press macro will do the trick.
For example, “a” tapped briefly ---> “a”
“a” pressed a little longer ---> does something else
If you really need it and are not exclusively fixated on KM, there are other apps that do this perfectly. For example BTT.
