I've encountered some unexpected behavior when having a macro with a Typed string trigger that also relies on a key set up to trigger a macro from a USB device key trigger. As shown in my test results below, there are numerous instances where the typed string trigger fails to fire as expected, at least here on my system:
M1 Max
Mac OS 26.0.1
Norwegian keyboard layout
KM v11.0.4
Test results below show which typed string triggers that trigger while the different test macros A, B and/or C are enabled (in addition to the "_0 — Typed string triggers" macro that was enabled for all the tests):
Enabled macros ➞
None
A
B
C
A+B
A+C
B+C
All
ﾠ↓ Typed String
"m1"
ㅤㅤ
ㅤㅤ
ㅤㅤ
ㅤㅤ
ㅤㅤ
ㅤㅤ
ㅤ ㅤ
ㅤㅤ
"mm2"
"M3"
"_4"
"__m5"
"mM6"
"_M7"
A — Macro with USB device key trigger for Shift pressed B — Macro with USB device key trigger for Shift released C — Macro with USB device key trigger for M-key pressed
When a USB device key trigger fires at the very beginning of a string, such as pressing Shift before typing "_4" or "M3", the Type string trigger triggers as expected — provided that macro B (Shift released) is not enabled (as the release of the Shift happens mid string). Therefore, it appears that the issue arises only when the USB device key trigger fires midway through typing a string trigger. Typed string trigger of "__m5" also triggers as expected (while only macro A enabled), as the Shift key is (usually) not lifted between the two presses of the Hyphen key.
Keyboard Maestro's typed string trigger seems to handle other instances of macros firing mid-string without any issues, I therefore find this behavior strange. Especially since the USB device key trigger normally should not interfere with the normal operation of the key press (as also explicitly stated in the wiki).
Is this expected behavior? Has anyone else encountered similar results to what is seen in my test results above? Am I the only one finding this behavior a bit strange?
I started testing your chart results, and didn't get the same results on my iMac. For example, with all macros enabled, typing M3 does trigger, whereas it didn't work for you according to your chart. I'm not sure I want to test every box in your chart, but clearly we have some differences in results. Maybe there's a clue in that for you.
Do you have any other keyboard utility software on your Mac that could be conflicting with KM?
Thank you so much for trying it out, and very interesting that you're experiencing different results than mine.
Just to be certain: Did you re-add the USB device keys in the triggers of macro A, B, and C, with Shift- and M-keys, from your USB device, as in your keyboard?
I cannot, from the top of my head, think of anything specific for my system that could be causing this issue. I do not, for instance, have Karabiner Elements currently installed, as this has been causing issues for me in the past. But I will definitely give this a thorough examination, as breakage of my KM Text Expander macros is a real issue for me.
Thank you! With this information, I guess what I've observed is to be expected.
I am sure there is a good reason or necessity for the typed string trigger buffer to behave in this way behind the scenes, but still I'd like to ask if it is at all possible that this could be built differently for a future KM update?
Secondly: This information about the Typed String trigger buffer being cleared, both when a Hot Key and USB Key trigger fires, would be very valuable information for the wiki. This was not at all intuitive for me to understand, at least not when stumbling upon it, and testes this yesterday.
If someone with permission to edit the wiki could add a note about this, it'd be truly wonderful. Both under Typed string trigger, and also under USB device key trigger., as this is an important counter example to the USB device key trigger normally not interfering with normal operation of the key.
As above, typing Shift-Space will cancel the sequence, as will any control key or command key (eg Command-.), any macro execution, switching applications, clicking the mouse, or not typing for more than a few seconds.
(Emphasis mine.)
This is something entirely different.
The key is operating "normally" -- only you've made "normal" include "triggers a macro", and executing the macro is what's clearing the Typed String buffer.
This is a very clear statement, only it is not true. As I also tested yesterday, there definitely are some triggers not interfering with the Typed string trigger buffer. And testing some more triggers here now shows that, at least, mid-string firing of the: Periodic trigger, Time of day trigger, Power status changes trigger, Mounted volume trigger, and USB device trigger, does not clear the buffer.
However, further testing here now shows that the firing of any triggering event from a USB device key trigger, also from a non-typing key, seems to clear the Typed string trigger buffer, so this is in accordance with Peter's statement above.
Although that also depends on what the macro does. A mouse-move doesn't, a mouse-click does. Moving a window doesn't, simulating a keystroke does. A Notification doesn't, insert-by-pasting does. And so on.
Fortunately most of those "interrupting events" aren't things you'd typically have in a macro that was meant to run both without deliberate user initiation and when the user is active on the keyboard
Originally, any macro triggered would clear the typed string buffer. This was later relaxed to only actively executed macros like USB keys and hot keys on the assumption that something like a timed trigger will not be created to interfere with the UI.
If you trigger a macro, then all sorts of things could change resulting. If you type part of a Typed String trigger, then trigger a macro, then type another part of the typed string trigger, it’s not safe to execute that trigger. The entire context could be changed.
Similarly, things that change the context, like clicking or changing application clear the Typed String trigger buffer.
The Typed String trigger is intended to trigger only when the string is typed, in its entirety, without other things happening while you type it. Anything else would be too dangerous, especially with the characters typically being deleted afterwards which is more than dangerous enough as it is.
Exactly. Basically, if the macro is actively triggered by the user, of if the macro does anything that could change the context in which the typing is happening, either of those will clear the Typed String buffer.
If the macro is periodically triggered and logs something to a file, that sort of thing will not because it is happening entirely in the background.
Obviously, this is not foolproof, but this is how Keyboard Maestro is designed to limit the likelyhood of erroneous execution of a Typed String trigger.
ㅤㅤ