Is it possible to add the "Asynchronously" flag to the "Execute a Subroutine" action?

Questions & Suggestions
1

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.

2 Likes
2

I hadn't realized you couldn't use it asynchronously, but like you said, if it returns a value, then it probably can't be asynchronous.

@peternlewis Any chance you might add Async to subroutines, if they don't return a value?

1 Like
3

Thanks, Dan. I agree that there's a good reason not to implement this, and we both know the reason, but I made my best case.

I realize that over 80% of my ideas never get implemented. But maybe if this one is rejected, I'll be getting one step closer to one of the 20% of my ideas which do get implemented.

2 Likes
4

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.

5

Thanks. Understood.

6

Well, let's think this through.

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. :wink:

1 Like
7

But I think you ask him as many questions as you answer on his behalf. :wink: Net zero.

1 Like
8

I would also like a Subroutine that could be called asynchronously!

Definitely need to handle "Returning a value".

For now I will use a wrapper Subroutine for the convenience of naming variables. The subroutine will call another macro asynchronously using "With Parameters" that will be carefully delimited.

Not pretty, but workable. The biggest pain will be that I'll have to add/remove parameters in 2 places.

9

That does not make sense.

If the Subroutine is called asynchronously then how would the value be returned? The calling macro would have moved on and there would be nowhere for the return value to return to.

10

I don't mean to handle it by getting the return value somehow. I mean that if running asynchronously, then the return value should be "handled" by ignoring it.

1 Like