Limit Hot Key triggers to specific applications?

Hi folks,

Is there a way to set a Hot Key trigger that will only run its macro in specific applications?

I'm trying to set up multiple macros with the same Hot Key, dependent on application, that won't conflict.

Thanks!

Sure. All you need to do is make different macro groups for each application.

3 Likes

@gglick is right and that is the best way I have found. The thing is though that in Keyboard Maestro it doesn't matter if they do conflict in a sense. There is a ingeneous way of sorting that out. The conflict pallete which I use all the time.

I often set the same hotkey for similar but not identical jobs and then let the conflict pallete sort it all out.
If you name or number the hotkeys carefully you will not find much friction in terms of speed I have found. I find I don't remember multiple hot keys that way anyway. So it is better for me to see them in the conflict pallete. There is a feeling, an intuition that the 'conflict' pallete is not legit in some way: the name says it. But I find it is a very effective way of working. In fact most of my hotkeys come up in them.
Here is one that comes up with F2 key for me, I would say it is my most used hotkey.

The solutions from @gglick and @tudor_enyon are valid, but have some issues. Their approach can result in code being duplicated and spread out across different macro groups. If something changes, the code has to be updated in multiple places. If each macro is very different then there is no problem, but if they are all similar, then updates are tedious and it's easy to miss one of the groups or make a mistake somewhere. Also, if the palette pops up, that's an extra step in the workflow. Again, there's no problem if that's what you want, but others might prefer a single-step trigger.

My approach is to use a single hotkey in a single macro group that will fire no matter which application is active, but perform different steps depending on the context. I accomplish this using the "If Then Else" action under "Control Flow".

In the following example, I want Control+End to always move to the end of a document, but different apps have different shortcuts for that functionality. My solution is to use "If Then Else" to simulate the appropriate shortcut based on which application "is at the front".

2 Likes

Yes, nice. I am starting to use those and I think it is a very neglected strategy. I think David Sparks said he doesn't use it at all, I am not sure now. He did mention it though in his guide. I really think it is one of the most useful actions on Keyboard Maestro.
I take your points about organizing macros in a sensible way and the points you make. I have managed to avoid doing that. Don't forget I have a relatively small number of macros and I should have said that.

The solution to this common programming issue is to use what many of us call "Sub-Macros", which are other macros called from the main macro using Execute a Macro action.

So put your common KM Actions in a separate Macro (Sub-Macro) and call it from every main Macro that needs those Actions.

Let us know if you need any help in implementing this approach.

So the strategy is to put different macros in different Macro Groups, where each MG restricts availability to specific application(s). Each of these Macros can still have the same trigger, but because of the MG the correct Macro will always be triggered.

Make sense?

1 Like

Yes it makes sense @JMichaelTX.
That will be very useful to me. I don't have a large number of macros, but they are building up slowly to my surprise.

Thanks for suggesting to use the 'Execute a Macro' action for modularity. I have used that action before and it is another good way to avoid duplication and simplify maintenance. It is nice that KM provides a variety of mechanisms for accomplishing tasks in different ways. The user is ultimately able to tailor things to their specific use cases and preferences.

In my example, the sub-macros would not make sense because there is no need to create multiple additonal macros that would each contain only a single keystroke action. Also, the example is already in a macro group which uses the include/exclude applications feature of the group for another purpose, so that approach was unavailable in this case.

The macro groups and control flow options are not necessarily either/or propositions; they can be combined and nested for more advanced filtering based on which application is active.

1 Like

In that case I would agree, using a Switch or Case action based on App would make more sense. I inferred from your earlier remarks that you had many common Actions that are needed for many Actions per App.

If most of the Actions are common across many apps, then a single Macro using a Switch or Case action to execute the few Actions unique to each App you make the most sense.