Hmmm, not sure what the use case is – why you need a macro to press ^R when a keypress will do the same thing, but you can use the “Show Macro Group” action and configure it to “Show Palette for One Action” – configure this to choose the macro group that contains the ^R set.
The use case is that I have a multi-purpose macro triggered by the “FWD” and “BACK” buttons on my Logitech Trackball. The macro provides different behavior for different apps. In the case of KM, I want the FWD button to trigger the Conflict Palette for macros that display the Recent Run Macro, and Recent Edited Macros, and then I’ll choose. The BACK button triggers toggle of last edited macro.
Using these two buttons on my Trackball, I can easily/quickly do any of these:
Toggle to last edited macro
— and if it worked —
Display/pick from recent run macro list
Display/pick from recent edit macro list
In other apps the buttons select prior or next tab, prior or next document, etc.
I see no reason why KM should not be able to trigger one of its own macros using its hotkey. But maybe @peternlewis can explain.
Hmmmm. I just tried this with the following Type a Keystroke action and the conflict palette that this keystroke triggers opened successfully. Not sure why, since I couldn’t get a test version to work when I used what @JMichaelTX posted above (^R):
Same here, LOL. It would be interesting if KM would let us create groups on-the-fly – say, by having a sort of “group variable” that is a defined as a set of macro names. (Or a set of macro names & macro groups).
This is basically the same issue as typically seen in reverse when people try to capture a key (Trigger hot key Control-R), and then conditionally type the key to perform it’s actions (Type a Keystroke: Control-R).
It is undefined what will happen if you simulate a keystroke that is a hot key trigger.
So the behaviour you get will be either:
triggering the macro (in this case resulting in the conflict palette as hoped) or
typing the keystroke (in which case whatever Control-R does would happen (which on the Mac is normally nothing)).
and there is no way of predicting which you will get.
Keyboard Maestro tries to get the latter behaviour (which is what you are actually seeing) but because of the keyboard event queue it is impossible to guarantee (which is why people often see the other behaviour, especially in Sierra where something subtle has changed in the timing that causes the former behaviour to be far more prevalent).
I understand the desire to trigger the conflict palette from a macro (its actually on the todo list), but currently there is no way to do it directly.
Probably if you use an AppleScript to simulate the keystroke, that would reliably work to trigger the macro (since Keyboard Maestro would then not be trying to get the latter behaviour).
And probably Keyboard Maestro should just give in and accept the former behaviour as the definitive behaviour because that at least would be reliably consistent. But in generally when you’re simulating a keystroke you do not actually intend to trigger a macro, so the latter behaviour is preferred.
@DanThomas, of course you are always free to work on whatever interests you.
In this case, I think there are a number of KM direct solutions/workarounds for achieving this. And my use case is probably a seldom needed use case. So, I’m not sure how many would need the macro you proposed.
I know you have a lot on your plate, and I just wanted to share my thoughts with you.
Is it feasible to add an option to the “Type a Keystroke” action to specify which of the two outcomes would always result – so the result would no longer be undefined? I assume the default would be “type the keystroke” and the optional alternate would be “tell KM to trigger a macro” and if there is no macro defined with that keystroke then we go back to the default.