Cancel This Macro - Other Instance

[egooner]

It would be helpful in some instances to single thread a macro.

Either enable a macro to auto cancel other instances of itself or allow the Cancel Macro to cancel other instances of itself but not itself.

I have a couple of triggers on a macro that in some instances can trigger quickly - eg WiFi drop and reconnect. It would be helpful to ensure that only one instance is running.

 

[Dm114]

It would be helpful in some instances to single thread a macro.

Either enable a macro to auto cancel other instances of itself or allow the Cancel Macro to cancel other instances of itself but not itself.

I have a couple of triggers on a macro that in some instances can trigger quickly - eg WiFi drop and reconnect. It would be helpful to ensure that only one instance is running.

Unless you have endless loops, each instance is supposed to end after the actions are performed.

Anyway, Cancel Macro action cancels all running instances of the designated macro.

 

[egooner]

Understood. - that's the point - it would be helpful (in some circumstances) to be able to only run the latest instance from the latest trigger - or to be able to cancel the previous instances (if still running) and continue with the latest trigger only.

 

[Dm114]

Understood. - that's the point - it would be helpful (in some circumstances) to be able to only run the latest instance from the latest trigger - or to be able to cancel the previous instances (if still running) and continue with the latest trigger only.

As it's impossible to cancel one specific instance of a macro, you'll have to end programmatically the running routine when a new one is about to begin.

With some boolean variables, the principle could be this one:
- when a trigger fires, ask IF... [already_running]?
- if the answer is YES (True), set [asking_permission_to_run] to True and Wait untill [already_running] becomes False, then set [already_running] to True and [asking_permission_to_run] to False then run the rest of the macro as described below,

- when a trigger fires, ask IF... [already_running]?
- if the answer is NO (False), set [already_running] to True, run the rest of the macro and test at some particular points of the routine IF [asking_permission_to_run] is True. If so, go to the end of the routine.

- in both cases, at the end of the routine, reset [already_running] to False.

HINT: as there is no GOTO statement/action, to go to a specific point, you can include every specific sequence in a Run 1 time loop and Exit loop to abort the routine when necessary.

 

[egooner]

That's why this is in Feature Request!!
The problem is knowing at what point the 2nd trigger will happen.
Hence the need to cancel from the new task.

 

[Dm114]

That's why this is in Feature Request!!

Sorry I didn't notice it was a Feature request. I'm afraid it won't be possible, mainly if it would require lots of development for a limited usage. But let's @MacroDroidDev answer by himself.

The problem is knowing at what point the 2nd trigger will happen.
Hence the need to cancel from the new task.

Generally triggers fire every time the specified event occurs, whatever the state (running or not) the concerned macro is.

The only case I noticed trigger happens not to fire is "Application closed" when an (new) "Application launched" fires. So the expected cycle
"Application launched" => "Application closed" when => another "Application launched" becomes
"Application launched" => another "Application launched"...
It's a bit embarrassing to follow the life (in foreground) of an application

 

[egooner]

It's not that the trigger doesn't fire. It fires but if the task is still running when the 2nd trigger fires I want the first task to end immediately and allow the new task that has been triggered by a different trigger to run instead.

 

[Dm114]

It's not that the trigger doesn't fire. It fires but if the task is still running when the 2nd trigger fires I want the first task to end immediately and allow the new task that has been triggered by a different trigger to run instead.

It is exactly what I described above.

 

[Snurre]

as there is no GOTO statement/action, to go to a specific point

This would be so great if it could be implemented sometime

 

[egooner]

As an added reason for wanting this.
Below is the test output from a simple script listening on two intents 1 and 2 called from Tasker which also passes a variable stored by the trigger in the same variable. As you can see the local variable is overwritten by the 2nd call so variables do not appear safe between calls. I get the logic for this but it means the original script is not safe from modification by the second one.

```
[2023-04-29 17:13:10] - Intent 1 Started one
[2023-04-29 17:13:15] - Intent 2 Started two
[2023-04-29 17:13:25] - Intent 1 Ending two
[2023-04-29 17:13:25] - Macro Done two
[2023-04-29 17:13:30] - Intent 2 Ending two
[2023-04-29 17:13:30] - Macro Done two
```

 

[Dm114]

As an added reason for wanting this.
Below is the test output from a simple script listening on two intents 1 and 2 called from Tasker which also passes a variable stored by the trigger in the same variable. As you can see the local variable is overwritten by the 2nd call so variables do not appear safe between calls. I get the logic for this but it means the original script is not safe from modification by the second one.

```
[2023-04-29 17:13:10] - Intent 1 Started one
[2023-04-29 17:13:15] - Intent 2 Started two
[2023-04-29 17:13:25] - Intent 1 Ending two
[2023-04-29 17:13:25] - Macro Done two
[2023-04-29 17:13:30] - Intent 2 Ending two
[2023-04-29 17:13:30] - Macro Done two
```

This behaviour is quite normal and it's the reason why I suggested a bit earlier the scenario were the macro manages by itself what and when this or that part of the macro will run.

 

[Endercraft]

An update for all that request this..

Unfortunately this is way more complex than you can really imagine and macros don't run in their own isolated sandbox to make this possible. If I was creating MacroDroid again from scratch now with the knowledge I have now I would certainly structure everything differently, but we are where we are.

The simplest way to achieve what is desired is to move all functionality into an ActionBlock and then you can cancel that instance of an action block from within using the exit action block action.