Cancel Action Block

[cwallen19803]

In the same way that I can Cancel Macro Actions, I would like to Cancel Action Block.

The list of code objects in the Cancel Macro Actions submenu includes only Macros.

 

[tanutanu]

In the same way that I can Cancel Macro Actions, I would like to Cancel Action Block.

The list of code objects in the Cancel Macro Actions submenu includes only Macros.

I can't imagine the situation when you want to cancel another macro running parallelly. The action block is guaranteed to be executed entirely by such an isolation, excluding cancellation by itself.
If you want to make it just a part of your macro sequence, legacy jump and come back technique might help you. Otherwise, put the target action block for cancellation in the running action block logic and return the fact in the output parameters, then determine to cancel or not in your caller macro.

 

[cwallen19803]

I can't imagine the situation when you want to cancel another macro running parallelly. The action block is guaranteed to be executed entirely by such an isolation, excluding cancellation by itself.
If you want to make it just a part of your macro sequence, legacy jump and come back technique might help you. Otherwise, put the target action block for cancellation in the running action block logic and return the fact in the output parameters, then determine to cancel or not in your caller macro.

If an action block can be canceled by it self then there is no reason I can't ask to have it canceled externally. The end result is the same.

 

[tanutanu]

If an action block can be canceled by it self then there is no reason I can't ask to have it canceled externally. The end result is the same.

Please imagine which instance should be cancelled when 2 or more action block instances are running.

Even normal macro, in my opinion, no need to cancel another. Do you know how the cancel action behaves? General MD macros are always running a chunk of action statements until reaching a wait or the end. The current is moved to another sequentially, so the cancellation doesn't always terminate another immediately. If your parallel running macro has no wait, the cancellation does no make sense, the timing is determined by its actions.
One important difference between normal macros and action blocks is how they handle the wait actions, which determine these execution order.

 

[cwallen19803]

Please imagine which instance should be cancelled when 2 or more action block instances are running.

Even normal macro, in my opinion, no need to cancel another. Do you know how the cancel action behaves? General MD macros are always running a chunk of action statements until reaching a wait or the end. The current is moved to another sequentially, so the cancellation doesn't always terminate another immediately. If your parallel running macro has no wait, the cancellation does no make sense, the timing is determined by its actions.
One important difference between normal macros and action blocks is how they handle the wait actions, which determine these execution order.

Perhaps you should take this up with the developer. The Cancel Macro Action exists. If you don't see a need for it, or are unable to imagine a use, then you are under no obligation to use it.

"Please imagine which instance should be cancelled when 2 or more action block instances are running."
I image that both instances would be terminated.

Again, how is Cancel Action Block any different that the current, existing Cancel Macro Actions?

Feel free to lobby against Cancel Macro Actions with the developer. If you're against cancelling macros then I can understand how you would be against cancelling action blocks. That's your opinion, but not one I share.

 

[tanutanu]

Perhaps you should take this up with the developer. The Cancel Macro Action exists. If you don't see a need for it, or are unable to imagine a use, then you are under no obligation to use it.

If nothing is wrong, I accept it as you told, as same as canceling standard macros.

"Please imagine which instance should be cancelled when 2 or more action block instances are running."
I image that both instances would be terminated.

Again, how is Cancel Action Block any different that the current, existing Cancel Macro Actions?

An action block is executable from 2 or more macros(or even action blocks) at the same time, while a macro is never duplicated. A macro is always running as unique one.
Each action block should be instance, working parallelly, having no influence each other or from another caller(s).

It is completely isolated. It means;
macro A -- call --> AB a -- return --> macro A
macro B -- call --> AB a' -- return --> macro B
Action Block C -- call --> AB a'' -- return --> Action Block C
Action Block D -- call --> AB a''' -- return --> Action Block D

If Action block instance E can cancel all the instances of the above ABs as you said, I can't use any action blocks safely. Now it works as a safety mechanism to avoid unintended mistakes. Don't you feel the benefit?
I don't think you would always like to cancel all. Probably you want to limit a certain scope and not at all sometimes. It is quite different things that an AB instance itself die and is killed by others. Please note that an action block and a macro(or another action block) is NOT a relation of 1:1.
If you prefer just a chunk of actions running sequentially but want to split to 2 or more parts, jumping with run macro action is suitable. You can cancel your macros whichever you want regardless where it runs.

 

[cwallen19803]

If nothing is wrong, I accept it as you told, as same as canceling standard macros.


An action block is executable from 2 or more macros(or even action blocks) at the same time, while a macro is never duplicated. A macro is always running as unique one.
Each action block should be instance, working parallelly, having no influence each other or from another caller(s).

It is completely isolated. It means;
macro A -- call --> AB a -- return --> macro A
macro B -- call --> AB a' -- return --> macro B
Action Block C -- call --> AB a'' -- return --> Action Block C
Action Block D -- call --> AB a''' -- return --> Action Block D

If Action block instance E can cancel all the instances of the above ABs as you said, I can't use any action blocks safely. Now it works as a safety mechanism to avoid unintended mistakes. Don't you feel the benefit?
I don't think you would always like to cancel all. Probably you want to limit a certain scope and not at all sometimes. It is quite different things that an AB instance itself die and is killed by others. Please note that an action block and a macro(or another action block) is NOT a relation of 1:1.
If you prefer just a chunk of actions running sequentially but want to split to 2 or more parts, jumping with run macro action is suitable. You can cancel your macros whichever you want regardless where it runs.

"while a macro is never duplicated. A macro is always running as unique one"
Not true. A macro with multiple triggers can execute in parallel.

"I don't think you would always like to cancel all"
Presumptuous, at best.

Please stop trying to teach me how to code.

So, you are right and I am wrong.

 

[tanutanu]

"while a macro is never duplicated. A macro is always running as unique one"
Not true. A macro with multiple triggers can execute in parallel.

No, if you think not true, write a simple test code please.
If a macro without any wait actions is running and the same macro was executed by another trigger, the following is starting after the first one finished.
If with waits, the following is starting when the first one points the wait action, and each wait will be a turning point to another.
If the following is another macro, it starts immediately and swiches back at the point of a wait statement(if it has).

"I don't think you would always like to cancel all"
Presumptuous, at best.

Please stop trying to teach me how to code.

So, you are right and I am wrong.

I don't talked what was right or wrong. We all agree or disagree when something is requested.
As Jamie asked, we have to consider what is better for everyone. Sometimes a discussion helps to clarify what a guy really want or makes it better. I believe nobody wants to say it was not what he desired after Jamie would spend time to implement.

Anyway I was not willing to lecture at all. Please don't feel bad. I hate that like you

 

[cwallen19803]

Code this macro. Test the empty trigger.
Watch it eat your machine as a be instance executes once a second.

Clearly you can execute one macro multiple times, in parallel.

When I tested it, 5219 instances had started, none got further than a=a+1. None displayed the value of a, and the wait never occurred. Macrodroid crashed.

Give it a go

 

[tanutanu]

Code this macro. Test the empty trigger.
Watch it eat your machine as a be instance executes once a second.

Clearly you can execute one macro multiple times, in parallel.

When I tested it, 1675 instances had started, none got further than a=a+1. None displayed the value of a, and the wait never occurred. Macrodroid crashed.

Give it a go

That's what I told.
It is natural because the followings are executed at the point of wait action and doing it continuously. Put it into while loop with the condition a<10 or so, you can see ax5min wait. It works sequentially, just interrupted(and suspended waiting the followers finish). So, It always run single instance at the same time.

 

[cwallen19803]

I took the wait action out. Same results. Explain. Try actually testing it yourself.

 

[Pseudocyclic]

Macros can definitely be run multiple times concurrently (regardless of how many triggers they have).

 

[tanutanu]

I took the wait action out. Same results. Explain. Try actually testing it yourself.

It is also natural that each macro run simply finished one by one without the 5min wait, a++ increment is enough cheap and popup doesn't wait its disappearance. Try heavier action, parse long text with regex or something. Just str=str + a 500 times string handling might be good and easy example instead.
The point is that all regular macros, even another macro, always share single linear thread and run statements step by step sequentially, while action blocks are running parallelly. As the pros, the isolation feature of action blocks, wait actions inside an action block is guaranteed its time length, never interrupted due to another instance of the action block or another macro run.

 

[cwallen19803]

Please post the results of your test run of my macro, an image of the log file as proof. Explain in 25 words or less why line 3 never executed.

Be succinct.

 

[cwallen19803]

All hat and no cattle. Idiom of the day.

To be honest, I don't know what your point is. I just want to be able to cancel action blocks and you launch into a macro tutorial I didn't ask for.

An example of how a macro can only exist as a unique one from you would go a long way to proving your point. To date you have only words and theory. Show me.

Anybody.

 

[Snurre]

In the same way that I can Cancel Macro Actions, I would like to Cancel Action Block.

The list of code objects in the Cancel Macro Actions submenu includes only Macros.

I don't really think that this is the meaning of using Action Blocks
As I read it, the purpose is to have some often used actions collected at one place instead of redundance in x macro's for ie maintenance and so on

Action Blocks - MacroDroid Wiki

macrodroidforum.com

So if you want to break out, why not just call another macro with this action instead of Action Block

Or what about this

 

[cwallen19803]

I don't really think that this is the meaning of using Action Blocks
As I read it, the purpose is to have some often used actions collected at one place instead of redundance in x macro's for ie maintenance and so on

Action Blocks - MacroDroid Wiki

macrodroidforum.com

So if you want to break out, why not just call another macro with this action instead of Action Block

Or what about this
View attachment 2217

Regardless, Cancel Macro Actions (this one) is a valid choice from WITHIN Action Blocks. Therefore I conclude that Action blocks CAN be canceled. In fact, I have already used the cancel action from WITHIN an Action Block. The world did not come to an end.

There is no harm in canceling an action block, or a macro for that matter, if you understand the consequences. Randomly cancelling a code block leaves some planned tasks undone. I. Understand.

 

[Snurre]

Now I totally lost it
You want to cancel an Action Block from outside the block, so why just don't run it?
I don't get it, maybe it's just me

 

[tanutanu]

An example of how a macro can only exist as a unique one from you would go a long way to proving your point. To date you have only words and theory. Show me.

Exactly. goes off track but I showed you clearly on #4 and #8.
Again just increment a value processes super fast, Display popup command itself is also fast, so we insert few seconds wait sometimes.
The log is too long but you can see them if you want to figure out how statements order exactly. It's up to you how evaluate them.
Anyway, I noticed a small loop overrun bug to report through the test. Thanks for the good opportunity!!

 

[cwallen19803]

Now I totally lost it
You want to cancel an Action Block from outside the block, so why just don't run it?
I don't get it, maybe it's just me

Order of operations matter. Suppose an A has started, then another trigger would also start ab A. I may not want both instances to execute. It is entirely possible that they will interfere with each other. I would rather stop the first and have the second start the whole process over.

I cannot think of a way, as you suggest, to "just not run" an ab once it has started other than Cancel, hence the request. I hurt my back yesterday shoveling snow, so why just not get out of bed yesterday. That horse is already out of the barn on the train that has already left the station.

It is entirely possible that the first instance could already be finished and my Cancel will have no effect. There are many ways to code to determine if the first instance is still active. A global boolean, for instance.

I really don't see the problem in widening the scope of an action that ALREADY exists.