After reading the wiki section on the %ExecutingInstance% section (https://wiki.keyboardmaestro.com/token/ExecutingInstance), I'm guessing I'm overthinking what information or Format to place in the Instance area. I've tried the macro name, the UUID, etc. I'm stuck.
My simple macro is:
When Mail Quits
Cancel This Specific Macro - (called Mail Check)
I'm fine with being embarrassed that I couldn't figure it out. I'll take the L on this one. I just can't figure out what to put in that instance section.
Hmm... I didn't ask about canceling the action. I'm asking about the usage of the new Cancel a Specific Macro Action (see above Screen shot) that was introduced in v9.0.
Cancel a Specific Macro (v9.0+) — Cancels a specific macro instance (from the %ExecutingInstance% or %ExecutingInstances% tokens). I simply don't understand what to place in the Instance area.
I can't use the Cancel This Macro action for another action that is running.
So -- if I can't the new Cancel a Specific Macro Action for the purpose of cancelling another Macro, can you explain what this action does?
You can get an opaque string representing the executing instance of a specific macro instance - that is, each time a macro starts executing, that is a new instance (which also corresponds to a new set of Instance Variables) - by using the ExecutingInstance token.
If you squirrel that away somewhere, then another macro can use it to interact with that specific instance. In particular it can use the Cancel a Specific Macro action to cancel it.
It seems that Keyboard Maestro 10.0.2 does not (yet?) invoke "Catch" clauses in a macro instance which gets cancelled by means of "Cancel a Specific Macro", i.e. the macro instance appears to simply be killed off. Is this a bug or intended behavior (or even a wrong observation on my own part)?
You should be a product tester, because that's a good observation. I never would have even thought to test that.
However I'm not sure I agree with your desired behavior. If the catch clause wasn't cancelled, then the macro hasn't actually been (completely) cancelled.
I think your intention is for the macro to be cancelled at the end of the catch clause, but before the next action occurs. However I don't think that makes sense because if the macro isn't cancelled, then the action after the catch clause IS executed.
I see your point, that it might be useful your way, but I can also see how it could be useful the way it currently works. I suspect it would be a lot more work (for PeterNLewis) to handle the situation the way you are proposing. So unless you can make a really good argument for it, I suspect you won't get it to work that way.
I think there's a tolerable workaround for you. If you want to cancel a macro, just set a semaphore outside the macro and try setting the semaphore inside the macro in the place that you want the macro to be cancelled.
I think the purpose of the Try/Catch clause is to capture any error from the Try clause, not to capture any signals from outside the macro.
Thank you very much for your thoughtful and insightful reply!
In fact I am not sure what the "desirable behavior" should be in this case; I have just started experimenting with some more advanced features of Keyboard Maestro and wanted to find out more about try and catch.
My expectation was like "whenever a macro would normally terminate while executing the try block, it would instead continue executing the catch block", but this was not the case.
The Try/Catch action (v10.0+) allows you to execute a sequence of actions and catch any failure. If any action in the Try sequence would abort the macro, the macro instead continues executing the Catch section
The bold emphasis is mine, it indicates that "external events" like the invocation of the "Cancel a Specific Macro" action somewhere else, do not cause this effect. So the current behavior matches the docs (and perhaps indeed by intention).
I totally agree. Also because an action named "Cancel a Specific Macro" should do exactly what the name suggests, and cannot leave the target macro running. But you as the developer could always add another type of flow control action which might be called "Interrupt a Specific Macro" should the need arise.