###How Do I Trigger Macro by Its HotKey From Another Macro?
This does NOT work even though I have two macros with that HotKey.
It literally does nothing when executed.
I have two Macros in a [KM] Group that have the Hotkey:
When I press ⌃R it works as expected, showing me this conflict palette:
But when I issue the ⌃R by a Macro Action, it does nothing:
Any ideas on how to fix or workaround this issue?
Wouldn't the "Execute a Macro" action be another approach?
If I had only one macro with the HotKey, yes.
But I, on purpose, have two macros with the same Hotkey so that I will get a Conflict Palette.
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.
Or use BTT.
Good question.
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:
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):
Thanks, korm. That is what I have done.
In my multi-purpose macro triggered by my Trackball button, I have used this:
Works great! The only downside is that I had to create another Group, and I already have too many Groups. 
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).
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).
You mean, like Smart Groups?
No, a variable -- array containing macro names.
Well, obviously you can do this. What exactly do you want to do with the list of macro names?
I'm asking because there's always the possibility that I could create what you're asking for, if I understood it better.
Thanks for the offer. Just musing.
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:
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.
Thanks for the clarification. When I have some time, I'll add to the Wiki.
That would be great!
But at least we now know of a workaround.
Too bad.
I had the idea of making a macro that allowed you to create palettes on-the-fly, by passing a list of macros you wanted in the palette.
Technically, I suppose, they wouldn't be actual palettes, but rather Custom HTML Prompts that closely resemble palettes, but close enough.
But I guess that doesn't interest anyone.
@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.
Peter, thanks for the suggestion.
I tried this script, with and without the outer tell block, and it didn't work.
Same result as when a KM Action is used for the keystroke.
Maybe something is wrong with my script?
--tell application "Keyboard Maestro Engine"
tell application "System Events"
keystroke "R" using control down --- CTRL-R
end tell
--end tell -- KME
###Correction -- this works!
(EDIT: 2017-01-18 6:17 PM CT)
Need to use lowercase "r"
tell application "System Events"
keystroke "r" using control down --- CTRL-R
end tell
OK, thanks. And I understand the subtext also. Appreciate it. 
Thanks for the generous offer! If you ever want to try that, I'll be happy to work with it. 
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.