Some actions don't cancel if their parent macro is cancelled

When I run the following macro:... (you can ignore the emoji, they serve no purpose here)

... and then simultaneously run this macro with a different hotkey:...

...the first macro's window is not cancelled. The window sits there after all macros were cancelled. And then if I try to select an item in the window, the System Clipboard is not set to the value I selected. I'm puzzled why windows remain on the screen when the Engine isn't running any macros.

I started poking around with other input windows. The other common prompt window actions WILL close upon cancelling all macros, but the Prompt for Screen Rectangle actions does NOT terminate upon cancelling all macros, and even stranger, it DOES succeed in saving its data after its macro was terminated (!!), unlike the Prompt with List action.

In short, the Prompt with List action and the Prompt for Screen Rectangle actions do NOT cancel when their macro is cancelled, and one of them, only one, continues to function after the parent macro is cancelled. How can any action succeed if there are no macros running?

However if I cancel the KM Engine itself while either of those windows are open, even if the macros that created them have been cancelled, the actions will close. So they are still linked to the Engine, even though no macros are running. Strange.

I wonder how many other actions continue to run after the macro that created them has been cancelled.

I've seen this behaviour with the Display Progress action.

1 Like

@peternlewis This sounds like a bug?

Yes, all the windows are owned by the KM Engine process, so if the Engine stops, the the windows are killed also.

I mean, it's possible Peter kills them intentionally when the Engine stops, but even if he didn't, they would go away since the process that owns them ended.

I can confirm this.

Running a macro with a “normal” prompt, the prompt disappears when I cancel all macros, but not so with a “Prompt with List” prompt.

I guess this is related to the different behavior of these prompts:

When you click somewhere else (outside the prompt)…

  • A normal prompt doesn’t go away; macro keeps running because it expects a button click.
  • A “Prompt with List” prompt goes away, and the macro stops with that.

I tried to duplicate this and could not.

If I run this macro:

image

And then immediate try either of these actions:

image

The action is aborted at the end of the ten seconds and the prompt is canceled.

Note that Display Progress is different - there is no running macro/action behind the Display Progress window, the action sets the displayed window and the window continues regardless of what actions are run or canceled.

Yes, your way does not trigger the issue (that's interesting!) I just tried it your way, and that doesn't not replicate the issue. But I just tried it my way, again, and it does replicate the issue.

Create a macro that does a "Cancel All Macros" action (I use F19). Then, just "Try" this action:

image

Then press F19, and the prompt never goes away.

Just to be detailed, here's my F19 macro:

Very interesting! And, playing around, you don't even need the "Try".

It appears that there's a difference in behaviour between

  1. Run Macro A that pauses for 10 seconds then "Cancels All Macros", quickly run Macro B that shows a "Prompt With List" -- the prompt is dismissed
  2. Run Macro B that shows a "Prompt With List", hotkey-run Macro C that "Cancels All Macros" -- the prompt persists
  3. Run Macro D that pauses for 10 seconds then executes another macro that "Cancels All Macros", quickly run Macro B that shows a "Prompt With List" -- the prompt persists

Even more clearly demonstrated by this fun little Group, run "Main" and it will asynchronously run "Prompt", wait a beat, then run a "Canceler" that cancels all -- the prompt remains. Disable the "Execute Macro 'Canceler'" action, enable the "Cancel All Macros" action, run again -- this time the prompt is dismissed.

Cancel Demo Macros.kmmacros (4.5 KB)

It's almost like a "Canceler" macro will only dismiss the prompt if the "Canceler" macro has instantiated before the prompt-throwing macro...

My brain hurts. I'm sure Peter can figure it out from here.

1 Like

Correct (presumably on both counts, though I can't say for sure about your brain).

Fixed for the next version.

It is dependent on the order of execution of the macros for technically subtle reasons.

4 Likes