Is it possible to add the "Asynchronously" flag to the "Execute a Subroutine" action?
I guess it wouldn't be possible to do that if the subroutine returns a values, but many subroutines that I write don't return a value, so it could be sensible for them. I'm trying to use subroutines as often as I can, but I can't use them when they have to run asynchronously. I have to revert to passing data to a macro the old fashioned way: a single parameter.
I think I've identified, above, why it's not currently done, but I wanted to raise my voice on this anyway. It could be allowed, leaving responsible use to the programmer.
I considered it, but since you can change whether the macro returns a value or not in the macro trigger, that would then invalidate the ability to do asynchronous execution in the action, and that was too much of a can of worms for me to consider.
First, let's say you added an "Async" checkbox to the Execute a Subroutine action. You add it right below the variable name fields, which would place it directly below the "Save result to" field, if there is one.
When I "check" Async in an Execute a Subroutine action for a subroutine that does return a result, the "Save result to" field would go away. There's my visual cue that I can't use the return value along with Async.
If I have a subroutine that doesn't currently return a result, and I change it to return a result, I'd need to touch all existing actions that call the subroutine, if I wanted to actually use the return value. When I got to an Async action, I wouldn't see the "Save result to" field. This might be initially confusing, but no more so than with plenty of other situations. You could always decide to not actually hide the "Save result to" field, but make it disabled, with text in it saying you can't use it with an Async action.
I realize that these scenarios have a level of complexity, but honestly, if I have a reason to call something Asynchronously, I think that having this level of complexity shouldn't be surprising. And I know that's easy for me to say since I don't have to answer all your support request emails, but then again, to some respect, I kind of do answer some of them already.