Trigger for Invoking Macro from Drawer or Quick Run

[Abalsam]

When a macro runs from a shortcut or a widget button, a trigger is registered that can be tested for. However when a macro is run from the drawer or Quick run, no trigger is registered. This makes testing the various methods of invocation more cumbersome as I have to either test for all other triggers not to be true (process of elimination) or I have to sequentially test for the overt triggers and then if one is true mark a boolean variable as "True" then have a last test to see if the variable is "False".

It would be much easier if the method for Invoking the macro was always recorded somewhere and testable.

Thanks

 

[FrameXX]

This also applyes for invoking macros from MacroDroid notification.

 

[Abalsam]

This also applyes for invoking macros from MacroDroid notification.

I did not know that. Thank you.

 

[FrameXX]

I did not know that. Thank you.

Yes they also have no trigger.

 

[tanutanu]

When a macro runs from a shortcut or a widget button, a trigger is registered that can be tested for. However when a macro is run from the drawer or Quick run, no trigger is registered. This makes testing the various methods of invocation more cumbersome as I have to either test for all other triggers not to be true (process of elimination) or I have to sequentially test for the overt triggers and then if one is true mark a boolean variable as "True" then have a last test to see if the variable is "False".

It would be much easier if the method for Invoking the macro was always recorded somewhere and testable.

Thanks

Jumping actions such as Run macro action statement or test macro /actions on the top left... menu also skips triggers.
I'm not sure I cought what you meant exactly, all the differences are recorded in the system log and easy to recognize them Either triggered or skipped, all the triggers in macros have to be tested one by one. As a easy emulsion, test trigger on the context menu is helpful enough
Do you want to set a specific trigger as the default? And/or want to see which trigger fire in the editor screen when you choose test macro? Both test macro and test actions skip the triggers check. Only the difference is constraints in the bottom green field.

 

[Abalsam]

Jumping actions such as Run macro action statement or test macro /actions on the top left... menu also skips triggers.
I'm not sure I cought what you meant exactly, all the differences are recorded in the system log and easy to recognize them Either triggered or skipped, all the triggers in macros have to be tested one by one. As a easy emulsion, test trigger on the context menu is helpful enough
Do you want to set a specific trigger as the default? And/or want to see which trigger fire in the editor screen when you choose test macro? Both test macro and test actions skip the triggers check. Only the difference is constraints in the bottom green field.

If I am tailoring different things for the macro to do based on how it ran, I need to be able to programmatically see how it was started.

For example, if the macro initiates due to a stopwatch trigger do a. If via widget do b etc. But if the macro can't figure out how it was started it might error out or do nothing (as no conditions are satisfied). I hope that makes sense.

 

[Abalsam]

If I am tailoring different things for the macro to do based on how it ran, I need to be able to programmatically see how it was started.

For example, if the macro initiates due to a stopwatch trigger do a. If via widget do b etc. But if the macro can't figure out how it was started it might error out or do nothing (as no conditions are satisfied). I hope that makes sense.

To further elaborate, if the macro determines what it should do based on how the macro was initiated (ie testing triggers) if one or more initiation methods do not leave a trace, the program could end up doing nothing or fail to operate correctly due to incorrect user assumptions. That is why I believe all initiation methods should leave a trace visible to the macro.

In short, I am not worried about the user I am worried about the automation.

I hope that helps explain the request.

Thanks

 

[tanutanu]

To further elaborate, if the macro determines what it should do based on how the macro was initiated (ie testing triggers) if one or more initiation methods do not leave a trace, the program could end up doing nothing or fail to operate correctly due to incorrect user assumptions. That is why I believe all initiation methods should leave a trace visible to the macro.

In short, I am not worried about the user I am worried about the automation.

I hope that helps explain the request.

Thanks

Probably I got
I think there are no differences in all kind of the initiators such as MD drawer. They simply ignore a macro triggers and surely execute actions(if satisfied bottom constraints), so if you test via one of the variety, any others are ok.
On the other hand, you have to test all triggers in trigger continuous standard initiators. The trigger which actuality fired is recorded as a log in system log.
So I wonder you want to see it easier at grace, such as in another floating field on the editor screen instead of variables or unique HUD on floating popup notification.

 

[Abalsam]

Probably I got
I think there are no differences in all kind of the initiators such as MD drawer. They simply ignore a macro triggers and surely execute actions(if satisfied bottom constraints), so if you test via one of the variety, any others are ok.
On the other hand, you have to test all triggers in trigger continuous standard initiators. The trigger which actuality fired is recorded as a log in system log.
So I wonder you want to see it easier at grace, such as in another floating field on the editor screen instead of variables or unique HUD on floating popup notification.

Yes it is in the system log but can the macro quickly see/parse it? If not, it is not of value to the macro.

 

[420]

To further elaborate, if the macro determines what it should do based on how the macro was initiated (ie testing triggers) if one or more initiation methods do not leave a trace, the program could end up doing nothing or fail to operate correctly due to incorrect user assumptions. That is why I believe all initiation methods should leave a trace visible to the macro.

In short, I am not worried about the user I am worried about the automation.

I hope that helps explain the request.

Thanks

If it ends up doing nothing at all then that is your fault for not setting it up correctly , you should include an "else" in the if clause that checks which trigger fired.. Something like this:

if trigger fired - trigger A
run - action A
if trigger fired - trigger B
run - action B
else
run - action C
end if

I think the same as tanutanu, there are no difference between these triggers they probably all use the same method of invocation, for which there is no trigger, so they would all "run - action C" in the above example.

I mean if it is possible to have different/seperate triggers for everything (invoking from macro run/notification button/from drawer etc.) it would be great, but i'm not so sure that it is.. probably only the developer knows..

 

[tanutanu]

I mean if it is possible to have different/seperate triggers for everything (invoking from macro run/notification button/from drawer etc.) it would be great, but i'm not so sure that it is.. probably only the developer knows..

It makes sense
Each window would have the different contexts and roles. Especially quick setting tiles, it has not only the trigger function but the state indicator. Now MD notification bar icon has it as well, but also has its unique feature, flexibly modifiable rich visualized icon.

 

[Abalsam]

If it ends up doing nothing at all then that is your fault for not setting it up correctly , you should include an "else" in the if clause that checks which trigger fired.. Something like this:

if trigger fired - trigger A
run - action A
if trigger fired - trigger B
run - action B
else
run - action C
end if

I think the same as tanutanu, there are no difference between these triggers they probably all use the same method of invocation, for which there is no trigger, so they would all "run - action C" in the above example.

I mean if it is possible to have different/seperate triggers for everything (invoking from macro run/notification button/from drawer etc.) it would be great, but i'm not so sure that it is.. probably only the developer knows..

I agree if it ends up doing nothing it is my own fault (due to incorrect user assumptions). That doesn't mean I can't ask for a more robust trigger list to help me avoid those situations.

If I know about it in advance I can work around it . It's when I am unaware and make assumptions (that I do have all use cases covered when I actually don't) that this can be a problem.

Thanks

 

[Dm114]

When a macro runs from a shortcut or a widget button, a trigger is registered that can be tested for. However when a macro is run from the drawer or Quick run, no trigger is registered. This makes testing the various methods of invocation more cumbersome as I have to either test for all other triggers not to be true (process of elimination) or I have to sequentially test for the overt triggers and then if one is true mark a boolean variable as "True" then have a last test to see if the variable is "False".

It would be much easier if the method for Invoking the macro was always recorded somewhere and testable.

Thanks

There are 2 ways to invoke a macro: either Triggers (of all kinds) or "direct call" such as Drawer or Macro Run action.
Then it's up to you to check within the macro which trigger fired and what to do if no trigger fired i.e. the macro runs from "direct call".

 

[Dm114]

Then it's up to you to check within the macro which trigger fired and what to do if no trigger fired i.e. the macro runs from "direct call".

I generally do like that:
IF Trigger1 OR Trigger2 THEN...
ELSE IF Trigger3 THEN...
ELSE (Actions to perform when no trigger fired)
ENDIF

 

[Abalsam]

There are 2 ways to invoke a macro: either Triggers (of all kinds) or "direct call" such as Drawer or Macro Run action.
Then it's up to you to check within the macro which trigger fired and what to do if no trigger fired i.e. the macro runs from "direct call".

Which is what I have determined I had to do. But ideally I should be able to determine which "direct call" launched it.

 

[Dm114]

Which is what I have determined I had to do. But ideally I should be able to determine which "direct call" launched it.

If it comes from another macro, I use a global variable with the name of the calling macro. Something like: [v=RUN]=[v=RUN]<Called_macro_name,Calling_macro_name>

At the beginning of the called macro, if [v=RUN] contains '<Called_macro_name,.*>' (regex rules):
- extract the name of the calling macro ;
- erase <Called_macro_name,.*> to free [v=RUN]

 

[Abalsam]

If it comes from another macro, I use a global variable with the name of the calling macro. Something like: [v=RUN]=[v=RUN]<Called_macro_name,Calling_macro_name>

At the beginning of the called macro, if [v=RUN] contains '<Called_macro_name,.*>' (regex rules):
- extract the name of the calling macro ;
- erase <Called_macro_name,.*> to free [v=RUN]

Interesting idea. Thank you. However, since I try to make my macros stand alone (to make them more free user 5 macro limit friendly), I would not be starting one macro from another but rather initiating macros to run either via trigger or via user action. The initiation context would tell the macro what it is expected to do. This means: 1) I need to understand how it can be initiated (which I now do). 2) I need to understand how macrodroid can determine how the macro was initiated (which I am still learning) so that I can properly configure the macro and understand which initiation methods cannot be distinguished from each other and therefore must be treated as one method. 3) I want to ask the developers if they can make enhancements in macrodroid to address this in the future.

I hope that makes sense.

 

[Dm114]

Interesting idea. Thank you. However, since I try to make my macros stand alone (to make them more free user 5 macro limit friendly), I would not be starting one macro from another but rather initiating macros to run either via trigger or via user action. The initiation context would tell the macro what it is expected to do. This means: 1) I need to understand how it can be initiated (which I now do). 2) I need to understand how macrodroid can determine how the macro was initiated (which I am still learning) so that I can properly configure the macro and understand which initiation methods cannot be distinguished from each other and therefore must be treated as one method. 3) I want to ask the developers if they can make enhancements in macrodroid to address this in the future.

I hope that makes sense.

First of all, the best way would be to buy the Pro version for a couple of $, so you won't be limited by the number of macros anymore!
Then, I don't know whether other users would be interested by this enhancement. I personally don't really need it because I managed not to need it as I told you. On the other hand, don't forget that the Dev (@MacroDroidDev) is alone and works on MD during his free time and has to maintain it, first, and then enhance it according to users' demands taking into account the more popular and the less time consuming ones...

 

[Dm114]

Interesting idea. Thank you. However, since I try to make my macros stand alone (to make them more free user 5 macro limit friendly), I would not be starting one macro from another but rather initiating macros to run either via trigger or via user action. The initiation context would tell the macro what it is expected to do. This means: 1) I need to understand how it can be initiated (which I now do). 2) I need to understand how macrodroid can determine how the macro was initiated (which I am still learning) so that I can properly configure the macro and understand which initiation methods cannot be distinguished from each other and therefore must be treated as one method. 3) I want to ask the developers if they can make enhancements in macrodroid to address this in the future.

I hope that makes sense.

I've just read in your other thread that @MacroDroidDev is ok to add this feature in a future major version: lucky you!

 

[Abalsam]

First of all, the best way would be to buy the Pro version for a couple of $, so you won't be limited by the number of macros anymore!
Then, I don't know whether other users would be interested by this enhancement. I personally don't really need it because I managed not to need it as I told you. On the other hand, don't forget that the Dev (@MacroDroidDev) is alone and works on MD during his free time and has to maintain it, first, and then enhance it according to users' demands taking into account the more popular and the less time consuming ones...

I did buy the pro but I try to design macros to be all in one so that it is usable by all MD users including those using the free version with the 5 macro limit.