Although I have a feeling this might be more difficult to implement because I think these UI elements are provided by the system, so KM might not be able to create a link back to the editor like the Trigger Macro by Name Action UI can.
The KM Engine log will contain such alerts etc. so perhaps you could have a macro check that (using regex). I don't know whether it would be possible to provide the option-click mechanism that you want though.
By "you" I think you mean "I". I doubt this is a widespread need but we'll see what others say! Could it just be time to reorganise your macro groups? I find it useful to reconsider mine occasionally.
I have instance_debugMode defined as TRUE but disabled at the top of the macro. Then any time I do something I may want to trace later (in most cases for me, that involves knowing what I was doing when some subroutine was called), I just add the above Case statement. Nothing happens unless I enable the variable at the top of the macro, but if I do, I get this:
With the macro name in there (I hard coded it, but you can easily just use a token for that, and lots of other macro info), it's very easy to see which macro is doing what.
Yes I can certainly lose my way easily in such cases. Having more than one Editor window helps me quite a bit. For me it's not so much a problem to remember a macro's name so much as losing my place!
We can all have different challenges when working with KM and of course interact with macros in different ways, and I hope the levity in my previous reply didn't make it seem I was being snottily dismissive, which, reading it back now, I fear it may have. I was in fact disproportionately amused at the time by how hard it can be to generalise about "needs" in KM!
While it won't take you to the macro to edit it, don't forget that with any "blocking" dialog the macro is still running. So you can always remind yourself of the name by looking in KM's menu bar icon's "Cancel" list.
Yeah, that's a good idea. I should use that feature more often.
Yes, that too. It depends on the case.
i.e.: How new/old the macro is, how often I use it, how complex, etc.
Definitely.
Thanks for writing this. No problem
Definitely x2.
I try to think carefully before I post for this exact reason. But sometimes, the best way to find this out, is to post.
Generally speaking, I'm pretty reluctant to post places. But as others have commented (many times), I think one of the best characteristics of this forum is that everyone is welcoming, friendly, and helpful, regardless of skill level or whether the question, bug, or (in this case) feature request is going to appeal to most people or only a few.
Maybe the KM menu would be the better way to implement this[2] or as an alternative to my original idea if there's no way to add this directly to the Alert or User Input.
Maybe something like: Holding the option key while in the KM menu changes "Cancel" to a "Go to " sub-menu. Or maybe it adds a Go to ▶ sub-menu altogether. Something like this.
Granted, it will only work this way when the macro is triggered by its... trigger.
If you're in the Editor and use the try button or Try action, it will only appear as Trying in the Cancel ▶ sub-menu. But in that case, you're already at that macro . ↩︎
Quite right, and one way or another, people bring up intriguing and surprising ideas. Testing those ideas is often helped by digging into what really prompted them (e.g. discussing to find out what the underlying, real need is), but trying to do that in a way that tries to be in a tone of relaxed KMaraderie[1] can backfire and seem combative if it's done clumsily, and that's the last mood I would want to provoke in, as you say, such a helpful and friendly forum. We all mean well here. off-topic , carry on…
Oh dear, someone open a window, that was a stinker. ↩︎
Something else that may be relevant and which I had forgotten till I stumbled upon it again just now is "Last Used" in the Keyboard Maestro Editor's menu.
View > Go to Macro > Last used
or ⌥⌘-U
Alongside that in the menu are Last Edited, Previous Edited and Next Edited.
And that bad news is that you can't (I don't think) macro this in KM -- because the last used macro will be the one you triggered to go to the last used macro... Unless you want to go spelunking in Engine.log, of course.
Or unless you want to run this from another utility:
tell application "Keyboard Maestro"
activate
tell application "System Events"
tell application process "Keyboard Maestro"
keystroke "n" using {command down, control down}
keystroke "u" using {command down, option down}
end tell
end tell
end tell
Yes! I've seen that come up a few times here and when reading through the docs.
Every time I see it I think: "Ohh! That will come in handy. I'll use that". And then I forget to use that.
Thanks for the reminder. Definitely relevant for this case.
That's hilarious I love it. I guess I'll have to try to memorize those keyboard shortcuts.
The first downside with Last Used that comes to mind is how other macros might still get in the way. I'm thinking of ones with the Periodic Trigger that are running every few seconds. Like a macro that's checking for idle or something like that.
But it's still a great suggestion. Thanks @kevinb and @Nige_S
...except that's fugly and isn't clickable (at least until we get Markdown in dialogs) -- it can't even be selected and used elsewhere. Although you might be able to write a macro that OCRed the frontmost prompt and opened the link... Hmmm... @Airy -- that's your area of expertise, fancy a go?
Another method, assuming that the dialog is synchronous and the macro is still running, would be to get all currently executing instances, get the macro name for each, maybe check those named macros for dialog actions, and offer a pick-list of matches to open in the Editor. The main problem is that you can't (AFAIK) go from instance UUID to macro UUID, you have to bounce through the macro name, which could cause issues if the name isn't unique...
You can use an AppleScript action. But the simplest method is probably the keyboardmaestro:// URL scheme, as above. More about that on this Wiki page.
Since I’ve solved this exact thing few months ago for my own - here is everything written down (dictated of course… )
To STOP and Edit any Macro that has any GUI Elements via Macro Actions you’ll need three Macros
Macto one ( which has the GUI element) that
sets a Global Variable or a meaningful dedicated Name as it is supposed to be set up with the UUID of it self later on …
it has a Variable that holds the %ExecutingThisMacroUUID% Token (set at the beginning of this Macro).
it also has a Variable that holds the %ExecutingThisMacro% Token since wie later need the Name of it.
it has a Variable that combines the other two because it is the Variable we will use as a Parameter. Set the Value of that Variable up by using the other two as tokens separated by a comma.
it calls Macro 2 asynchronously using a Parameter of type Variable using the Variable that holds the UUID an the Name before any GUI showing action like Prompt or Alert is called.
Macro Two (the asynchronously called one)
it uses the %TriggerValue% Token in a Variable which is used to set the Value of the Global one from earlier.
it has a Glabal Variable indicating it’s used for the Hot Key Option + Return/Enter (Value = False).
it also pauses until the Prompt or Alert is visible
then it pauses until Hot Key Variable is set to true.
Macro informs the User by showing a Prompt that the calling Macro with Name from TriggerValue will now be cancelled and then opened in the Editor.
now it uses the Variable that contains the TriggerValue information as token to set up the Value of the Global Variable which was set as first by Macro one.
Uses AppleScript edit command to open the Macro via its UUID (from TriggerValue as well)
macro Two cancels Macro one by using the Cancel a Specific Macro Instance Action set to the Value by Using the Variable token of the Variable that holds TriggerValue Information with the right indication for the array that only gives back the UUID.
Macro two cancels it self by using Cancel Just This Macro
Macro Three with Hot Key Trigger set to Option + Return
check running Macros using the %ExecutingInstances% token for Macro Two.
if Macro List contains the Name of Macro Two then set Hot Key Global Variable to True.
Macro pauses until the Global Variable that holds the Macro information is set up and checks if Name of Macro one and Two are not in the list (%ExecutingInstances%).
macro pauses again for Editor Window is frontmost and if Title contains Name of Macro one.
macro sets Focus to the Editors Macros Column
uses AppleScript to check if selected Macro‘s UUID is Equal to the UUID in Global Variable.
macro three cancels it self.
I hope I’ve not forgotten anything … not being able to write that by using my Hands or - the better - giving you a setup that shows everything with instructions on how to use is terrible but that’s my problem.
But the above way shows the way I’ve solved your issue for myself some time ago and I’ve implemented this into quite a few Macros … maybe 200 or so … refer these 200 to my description above as Macro one … if nothing until now made sense to you - now it probably should …
I doubt this is a widespread need but we'll see what others say! Could it just be time to reorganise your macro groups? I find it useful to reconsider mine occasionally.
" sub-menu. Or maybe it adds a 
. 
I love it. I guess I'll have to try to memorize those keyboard shortcuts.
