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.
When inserting this action, there is a string already in place for the Instance. It says, "THIS". I did not find that helpful. It made me think of object names of self and this, and it has nothing to do with that.
I think it woud be more help to replace "THIS" with something more descriptive, e.g.:
I'm still a little confused. Wny does it need to be a token for the specific instance? Why can it not be the macro name or the UUID of the macro?
I can see that basing it on an Executing Instance allows you to separate different instances of the same macro that might be running simulaneously, EXCEPT that the macro has to save the token in a Global variable. If it saves the token in a Local variable, other macros, like the one attemptig to kill it, will inot have access to the token. But a Global variable will be overwritten by every instance of the macro, so you'll only ever be able to kill the most recent, and cannot kill all of them.
The macro could include logic to conditionally save the instance to a global variable; or it could save it to a dictionary. In the latter case a macro could subsequently use the key to discern more information.
It doesn't need to be anything. It's a prefill with what is probably the most regularly chosen option -- "cancel this executing instance".
You can only cancel executing instances. If you want to cancel named-macro or macro-by-UUID instances you'll need to get all executing instances and then work through them checking name/UUID for each and acting appropriately.
Your comment implies that there would be negative consequences if you attempted to cancel a macro by name or UUID that was not actually running at that point. I don't see it. I understand that in the current system, that's the way it has to be done, but to me it doesn't have to be that way.
I never said that. Obviously you can't cancel a macro that isn't running -- the only negative consequence would be that the action failed to do anything (which may or may not need error handling).
here is some info for you … while the Instance Tokens work under the Hood by using the UUID‘s of the Macros they’re actually have to be verified in your logic by using the Names of the corresponding Macro UUID‘s.
Without extra work, of course - but if you’re dealing with duplicated Macro Names you will have to build upon the Logic and use the right Macro‘s UUID hardcoded in your workflow to ensure the Executing Instance you want to cancel is the right one.
While this is somewhat more work it’s gonna saving your butt when you’re not using unique Naming everywhere.
Too bad, that I’m not having an example for you at hand - because of my shoulder…
But I hope that you’re getting what I am talking about.
