since action blocks are new and rough and some issues have been raised (local variables) plus some bugs are popping up (eg. https://www.macrodroidforum.com/index.php?threads/bug-action-blocks-with-notifications-dialogs.2057/)
I suggest that action blocks are not developed further independently, it will be much effort with little return compared to the following proposal
1. enhance macros to have input and output variables (ie. transplant into macros the current code that defines the input and output variables for action blocks)
2. make a new action to call a macro as a subroutine (ie. as an action block)
this will be different than the existing 'macro run' and will essentially replace the recently introduced 'action block' action
that's all !
of course when a macro is called as a subroutine any triggers and constraints are irrelevant
and when a macro is run as a real macro then any input and output variables are irrelevant
it's generally expected that the macros are developed as true macros or as subroutines
but still it's possible to code a macro to function dually for interesting effects
this proposal has less development effort (there will still exist a single entity to manage, no need for future categories or separate backups/exports or whatever for the separate entity of action blocks), less restrictions in what an action block(subroutine now) can do and is free of new introduced bugs
I suggest that action blocks are not developed further independently, it will be much effort with little return compared to the following proposal
1. enhance macros to have input and output variables (ie. transplant into macros the current code that defines the input and output variables for action blocks)
2. make a new action to call a macro as a subroutine (ie. as an action block)
this will be different than the existing 'macro run' and will essentially replace the recently introduced 'action block' action
that's all !
of course when a macro is called as a subroutine any triggers and constraints are irrelevant
and when a macro is run as a real macro then any input and output variables are irrelevant
it's generally expected that the macros are developed as true macros or as subroutines
but still it's possible to code a macro to function dually for interesting effects
this proposal has less development effort (there will still exist a single entity to manage, no need for future categories or separate backups/exports or whatever for the separate entity of action blocks), less restrictions in what an action block(subroutine now) can do and is free of new introduced bugs
Last edited:
