Cancel Action Block

cwallen19803

cwallen19803

Member
tanutanu said:
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!!
Click to expand...


Please explain how the macro end notice is shown twice for each seq value, given that there is only ever one instance running.
 

Attachments

  • Screenshot_20220130-133358_Photos.jpg
    Screenshot_20220130-133358_Photos.jpg
    476.3 KB · Views: 7
  • Screenshot_20220130-131823_MacroDroid.jpg
    Screenshot_20220130-131823_MacroDroid.jpg
    922.6 KB · Views: 5
tanutanu

tanutanu

Well-known member
cwallen19803 said:
Please explain how the macro end notice is shown twice for each seq value, given that there is only ever one instance running.
Click to expand...
If you noticed how it strange, that's what I suspect as a loop overrun bug. The reason would be hidden in condition test, I guess.
 
tanutanu

tanutanu

Well-known member
cwallen19803 said:
With respect, it proves that there are two instances. If you believe otherwise, please open a bug report.
Click to expand...
Sure. I can express as followings:
As I told on the post #8;
1. 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.
2. 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.
3. If the following is another macro, it starts immediately and swiches back at the point of a wait statement(if it has).
Click to expand...
The 3rd rule is applied in this case. When the seq#0 macro processed seq++ statement, the seq#1 is executed and progress to the point seq++. At the moment of the #1 starts, the previous #0 is suspended. The seq#1 is also suspended and #2 is going. It repeats #0 to #300 and 299 of suspended macros stacked before the last run. It could not be 600 logically.
As your believable logic, if it truly works parallelly, The numbers of followings should be increased like 1, 2, 4, 8, 16, 32, 64, 128, 256(total 511>300) in each loop and I can figure out it in the system/user log. That's one of the evidence that only single macro is running at the same time.

So, why does the log records twice? Why 600 time? That's what I suspect as the bug. Probably when suspended and waiting the next macro ends, the previous macro points the next statement. I comment out the next if-endif code block entirely, the variable seq increment until 300 correctly. Therefore when the if condition tests, either withWait is true or false, the next while condition test would be true mistakenly. So, the logics in the while loop overrun. The unexpected extra 300 times ghosts are realized and recorded doubled when each start and end.

UPDATE: As my followup test, I understand it is NOT a bug. The reason why a sequence runs twice is extra "queue" of shell script action. It works as wait, so after a sequence increment the variable seq and pass the test in while condition, then stacks on the shell script action and next one goes ahead. Without shell script action, the stack point is only one at the increment statement. With shell script as wait, the points become 2, the wait and increment. It causes one more chance to sneak the while condition test.

Only one my misunderstanding is that the above quoted 3rd rule is applied not only to another macro but also to the macro itself when MD variable change trigger is called.
I wound like to apologize to you for providing such wrong information. I always used MD variable change trigger when one of my library function in another macro was called before the introduction of Action blocks. So, I misunderstood the behavior. I think run macro action has the same behavior, but sorry, I don't remember exactly(the way is too legacy for me).
Anyway, the test itself does no make sense for me but I got clarified the behavior more accurately. I really would like to say thank you again:)
 
Last edited:
You must log in or register to reply here.
Top