Tip: Using a Macro as Both a Subroutine and "Execute Macro with Parameter"

Tips & Tutorials
,
1

Did you know you can have a "sub-macro" that works both as a normal "Execute Macro with Parameter" action, and as a KM10's new "Execute Subroutine" macro?

You might wonder why you'd ever want to do such a thing. Well, in my case, I love the new Subroutine feature, but I have a lot of existing "sub-macros" that use %TriggerValue%, and I don't want to change every place that uses them. But I'll be using them again in future macros, so I'd like to be able to use them as Subroutines too.

For a lot of my sub-macros, I'll just leave them as-is, especially if they only have one parameter. But I thought I'd experiment with having an existing sub-macro use both ways of passing parameters, to see how well it works.

And you know what? It works perfectly, and it's easy!

Let's say I have a "sub-macro" that I call from a lot of places. (This is not a macro I call from a lot of places, but it's what I was working on when I got the idea):

image

It takes 2 parameters, separated by a pipe ("|") character.

Here's how I changed it. I added the "subroutine" triggers to the macro:

image

These are the variables I already parse %TriggerValue% into. I'll talk more about this in a moment.

Now all I have to do is enclose my existing "Parse TriggerValue" code in an "if" action (the green part):

image

and validate the parameters if I want to:

image

Nothing else changes.

Here's what the "Execute Subroutine" action looks like:

image

Way easier to understand than the single parameter with the pipe character. Yes, the parameter names are a little odd with leading underscores, but it's really easy to ignore them. If I wanted to, I could have named the parameters like this:

image

which would make the action look like this:

image

Admittedly, the parameter names look better, But then I'd either have to change the existing code to use the new variable names, or set the existing variables to the values in the parameter variables. Frankly, that's more effort than I want to expend, and I really don't mind how these parameter names look:

image

I haven't addressed the issue of return values, because I'm pretty sure I'll leave as is, but time will tell.

If you've managed to read this far, I hoped this helped. :slight_smile:

9 Likes
2

Thanks, Dan.
I pondered on this before but did not come up with a good solution. This is great.

From this forum I learned to use TWO underscores between "local"/"instance" and the variable name: "local__Var". The leading underscores will not show up. I know this does not solve existing single score variable issues, but it might be helpful to other forum users.

2 Likes