I'm not sure how to deal with this problem and was hoping to get some suggestions. It's about reusing macros which contain subroutines.
Say I have a macro A in macro group P which contains a subroutine X.
I'll represent that like this: Group_P(macro_A[sub_X])
I copy the macro A into a different macro group Q. So, now I have
Group_Q(macro_A[sub_X])
I can change this copy how I like without messing up macro A in group P, even though both macros have the same name.
Now my question is, what about the subroutine X? I would expect that Group_Q(macro_A[sub_X]) would fail because it depends on subroutine X, and subroutine X is not in group Q. I actually want it to fail because it has a dependency which is not in group Q. If I go and change subroutine X in group P, I don't want that to affect anything in macro group Q.
So, how do I do that? How do I guarantee that a macro in group Q only uses other macros in group Q and nothing outside of group Q.
I would put all dependent macros in Group Q (which eliminates the no-redundancy benefit of subroutines), or I'd try to add logic to the subroutine that prevents it from executing except for a set list of calling macros (or macro groups). I'm sure the latter is possible, but I've never tried to write such a thing.
-rob.
Yes, my plan was to copy the dependent macro X into group Q and have Group_Q(macro_A) call that one. In fact, I did that, assuming that if two macros had the same name, the one in the current macro group would be favored over the one outside the macro group. But apparently, that is not true: Group_Q(macro_A) still calls the subroutine X from group P.
You have to update the action that calls subroutine X to point to the one you copied into the group. You can verify which one it's calling by clicking on it then using the Select Macro pop-up item to see where it resides.
You can definitely have identically-named macros; I have hundreds named "Verify update," for instance. But you have to make sure you update each and every action to call the macro with that name in the group you want it called from.
-rob.
Thank you. The select macro pop-up is helpful (and hard to find).
I was hoping for something better for nested subroutine cases. Actions like these:
- Get macro_group of the macro currently running. Put that at the top of the macro.
- Before each subroutine, I would put a check: execute sub_routine if sub_routine is in macro_group.
I think where you are getting caught up is believing that the macro's group plays any role at all. It seems to me (speculative, but matches observed behaviors) that when you create an action to execute another macro or call a sub-macro KBM internally notes the UUID of the macro being called. That link is preserved even if one or both macros are relocated to different groups. Or renamed, for that matter.
As @devoy says, the name is just for your convenience -- KM only cares about the macro's UUID. You can see this if you look at the XML of an "Execute a Macro" action:
...
<key>MacroActionType</key>
<string>ExecuteMacro</string>
<key>MacroUID</key>
<string>FE92A75D-546F-44C5-AF70-D24272B2C821</string>
...
I'm not sure if you mean you want these actions, or you're already using them. But, just in case, have a play with the %ExecutingMacroGroup% and %ExecutingThisMacroGroup% tokens. Used within a subroutine, the first will evaluate to the Group of the executing macro and the second to the Group of the subroutine itself. So:
That's very handy, thanks for sharing that.
Whenever I have macros named the same, I try to always include a prefix, like [VSCode], that gives me an idea of either which group, or which application it's for. That way I always know I am executing the correct macro.
That's true most of the time, but 100% of the time. In AppleScript and JavaScript, you can trigger a macro by UUID or name. So it's possible to rename a macro and break things.
With that said, no sane KM user that I know of triggers a macro by name like this, for this exact reason.
Still, the name can serve a purpose.
I've done that on occasion, but it bothers my sense of aesthetics to see [MacroBackerUpper] Verify Update in the list of macros within MacroBackerUpper. I like to keep the names simple, especially in macros I distribute where a user may have to run one of those macros.
-rob.
Sorry, I should have been more clear.
In the "Execute a Subroutine" and "Execute a Macro" actions, the name is just for your convenience etc...
Oh for sure, if it's in the same group that uses it, I wouldn't prefix it either. I think I had a slight brain fart when I read your post.