This one seems like it is probably easy to do but the means how to do it escapes me. I am trying to run several different If Then Else actions and what I need is one reference macro that can have the same if statements so I don't have to go into the dozen macros that need the same exceptions. Is there a way to have a reference macro that first checks for the Window Title that the other dozen macros can reference and do the If Then or Else?
Not totally related but a shout out to @peternlewis I just discovered this past week the Group - Create Macro option and so love that I have been doing that the long way for years! I love all the group options that were added a few years ago, just hadn't explored that one yet.
I'm not sure if this will help, but I think you can avoid using the IF action to solve this problem. Consider this sample piece of code:
Essentially I'm using the Try action as an IF action. It works the same way, but it's so much easier to copy the Assert action. Moreover, I think it's possible to put the Assert action into a macro (if you really want to) and the macro can return an error if the condition isn't met. That way you don't need to copy the Assert action ever again. But I would prefer using the Assert action in most cases like this.
Another vote for a subroutineif you are looking for a way for your macros to share something that can be updated and they all then get to use the new version.
But if you want the same "base" action that can then be tweaked for each macro that uses it without those changes affecting other macros -- create your action(s) and then save them as a Favourite. That gives you a template you can drop in wherever you want but remains independent.
You could go either way for your example above, it really depends on how you want things to behave with future edits.
Don't forget that you can combine most (all, if your first condition should also reference the "Front Application" rather than "Pro Tools") of your conditions using "Title Matches":
Nope, you are just a lot smarter than me in knowing what to do here in Keyboard Maestro. I will have to play around with this more.
Instance Variables, local to a specific macro execution instance • Name must begin with “instance” (case insensitive).
• Restricted to a specific execution sequence.
• Available to the Macro where it was created and Sub-Macros of that Macro, for a given execution instance of the main macro.
• These variables are private to each execution of the same Macro, even when running simultaneously.
• Accessible by Prompt For User Input
• Accessible by scripts (when used in an Execute Script Action).
• Accessible by Custom HTML Prompt.
• Accessible by AppleScript with the instance specifier.
Thank you, this makes a lot of sense right off the bat and worked like a charm! This will be what I will do until I learn "Instance" variable(s)" and "Subroutine Return value" which this seems like it is pretty much doing that in some regards.
This is great and I will have to expand my knowlege here. It seems like I have done this in years past but the same "base" action right now like @Airy said is the easiest to wrap my head around.
Don't forget that you can combine most (all, if your first condition should also reference the "Front Application" rather than "Pro Tools") of your conditions using "Title Matches":
That is very cool and I didn't know you could do that! I just tested that out and it works like a charm. What is the ^()$ for, I did it without those and it worked just fine also.
The ( and ) are to explicitly show that it is matching "any one of the terms in this group" -- helps readability, and that helps when you come back to the macro days, weeks, or months later.
The ^ and $ are more important -- they anchor the pattern to the beginning and end of the tested string, respectively. Taking only the first term as an example, it would mean that out of
Save
Saves
1st Save
...only the first line matches, because the others don't both begin and end with "Save".
As soon as you see the option's working contains "matches", as in "title matches", you know the following will be a Regular Expression pattern and that's why ^ and $ act as anchors.
Because that one uses "title contains", which is a "normal" find anywhere in the front window title. So it would match the literal text "^(Audio|Aux)$" as well as "Document 1 - ^(Audio|Aux)$", or "^(Audio|Aux)$ - Edited", and so on.
I am still going through and learning the Instance Variables and Subroutines in practice and how to apply it to what I have.
I thought for what it is worth to anyone else coming along and trying out this method to at least post some downsides to the "Assert That Conditions are Met" if you have several to use.
While this is cool to use “Title Matches” it also makes it a nightmare to figure out what is causing a false positive quickly. However it will not work if you have multiple “Assert “That conditions are Met” actions. They all have to be in only one action even though the group has "Timeout Aborts Macro" checked and each action has “Failure Aborts Macro” enabled.
You can see how I have referenced the submacro above in the following image.
You are very gracious, this tutorial you put together was so very helpful, thank you very much for putting this together. I understand these Instance and Subroutines and how to all those variables much better now. You put together great tutorials and that was very generous of you to take the time to do that.
It is interesting that in the Wiki it says that Instance is Case sensitive but that doesn't seem to be the case.
Also kind of interesting that you can't use the Value Inspector for Instance or Local Variables to see what was put into them.
If you ever ended up making tutorial videos for sale or a Keyboard Maestro certification class I would be very interested in watching them or attending.
You have always been so good and kind at explaining things over the years and have so much knowledge and experience. The videos you have made on making favorites I used all the time for years until they broke on me. Still got to attempt to figure that out again.
When I try to view your video it says "Sign in to prove you are not a bot" and it refuses to let me watch the video, but it doesn't tell me how to sign in. I'm already signed in to YouTube on my other Safari tabs.
Not really -- consider the Scope and transient nature of local and instance variables.
If you do want to see the values of these, use the Debugger which will show the ten most recently modified variables for the running macro instance. You don't have to start the Debugger before your macro, you can add an action to open it near the part you want to troubleshoot:
It really helps a lot if I can read properly, my bad. That makes more sense.
Well I would happily pay for them and you of course could write beginner, intermediate, advanced and then have an Appendix with your many other things you have made to enhance and make Keyboard Maestro work even better since you have quite a lot of those.
Oh interesting, I thought maybe it would just show up for a breif moment or at least stick what was last put in there eventhough it won't live in the preference variables.
That's cool, I have tried the Debugger many times and no doubt there are ways I can use it better. It has been easier and quicker most of the time to put in popup dialogs and long pauses for me to see where Keyboard Maestro is at in the process and where macros fail. I'll have to mess with that for Intance and Local Variables. Thanks for sharing!
