Is there a way to trigger a macro on an application becoming active, but ONLY if it's activated by the application's dock icon?
Or rather, is there a way to bind a macro to the Dock icon for an application. So clicking on a window for the application or command-tabbing doesn't trigger it?
Thanks.
Hello @metaning 
No, not natively. BUT Keyboard Maestro gives you the toolset to build you that behavior for your self.
Be aware that this is NOT AN EASY TASK.
Greetings from Germany 
Tobias
OK, as an alternative, could I detect any other way of bringing an app to the foreground, and use those to create a macro stop event, so that only the dock icon activation would get through?
Hi, it's not obvious to me what your underlying need is here. The post How Do I Get The Best Answer in the Shortest Time to Questions on the KM Forum? gives useful tips regarding this.
The reply by the new account has been flagged for attention since it seems to have been automatically generated.
It's a refinement of my previous topic:
...but I figured I should keep it to a new thread because that one is effectively "solved".
Short version - the default behaviour of Finder is supposed to be that when you click the Finder icon in the dock when a different application has focus, a file browser window should spawn when finder becomes active if there isn't one open already.
This only works about 50% of the time, presumably because bugs. In my other thread I have a solution that works beautifully, but it works whenever Finder is activated. I wanted to see if there a way to narrow the scope to just the dock icon.
Thanks… although I wonder why using the Dock is central to your aims.
Would you not be better off using an alternative interface element of some kind? Maybe a KM palette? Again I am a bit hazy about what might suit you—I prefer to use the keyboard over clicking whenever possible.
I ask that because the challenge appears to be bugs in the version of MacOS that you are using, and I doubt that the Finder offers any relevant API that KM could access. If that's the case, well, maybe something could be contrived but, you can bet that @Nr.5-need_input is right in saying that it's not going to be an easy task!
There comes a point at which it's more productive to completely route around yet another MacOS UI defect than to try to devise a hack around it.
Well what I have now works, and works beautifully, so changing to something else to get a fractional refinement of what I have would be a net negative. 
The dock is going to be there regardless - I have currently... 57 apps (with status badges etc) permanently resident in the dock (then there's the minimised windows, folders, temporary running apps etc), which runs down the long edge of a 24" portrait screen, and because of the way my system is configured, what with all the screens etc, I'm not keen to mess with my basic interaction model.
My workflows are pretty dock-centric, and the KM version doesn't as far as I can see, do what the system one does.
You prefer a keyboard to interact with your system, I have a 7 button mouse under my left hand, a 23" Wacom tablet in the middle, and a magic trackpad under my right hand... and a keyboard, and three screens (but only one dock and menubar) in an arc around me.
So yeah, I'm well past the refine-only stage of this paradigm 
I see two system settings that may impact my ideas for solving this:
I see two possible ways to solve your problem.
However I'm not sure how fast your Mac is or how long it takes your app to start, so these approaches may run into timing issues.
I see a third possible solution. But in order to do that, you need to tell me exactly how apps may start when they are NOT started by the Dock. Once you tell me that I can check if this third solution is viable.
Right, understood—that's the key information that explains your underlying need in this case, which I couldn't have assumed.
I wasn't suggesting you change your ways but explaining why I was "a bit hazy about what might suit you". We all have our preferences that work best for us and they can vary quite a bit.
By the way and just in case you didn't know: you can let Apple know about MacOS problems here: Feedback - macOS - Apple – but what good that ever does, I don't know! 
The dock is always visible, and has no magnification effects, if that's what you mean by animations.
This is only applicable to Finder, and to switching the system focus to Finder, so with the exception of when it's manually quit and restarted, it can be assumed to be running at all times.
Basically I'm looking to refine this workflow to only happen when the dock icon is used to make finder active.
31 years driving Macs all day every day, I'm yet to see giving Apple feedback have any effect so far 
Then no.
The closest you'll probably get is to make an AppleScript app that activates Finder then runs your macro, and put that app in the Dock -- removing the original Finder item is not recommended though! Links to such deliberately omitted...
Another way would be to make a Trigger File for your macro and put that in the Dock. It would have to go at the "other end", being a file and not an app, so it depends on whether you want "like an app but easily confused with normal Finder" or "nicely separate coz not an app".
That's slightly unfortunate, because Finder is the ONLY app that does NOT animate its icon to move when launching it.
Nonetheless we don't really need to use the Finder Icon if we can use the location of the mouse on the screen. Here's a short macro that will do what you want. In my case, my Dock is on the left side of the screen. Maybe yours is too - you didn't say. If yours is somewhere else, you will have to modify this code slightly.
This macro will play a sound whenever the user clicks on the Finder icon in the Dock on the left side of my screen.
Does that also fire off when an already running application is brought to the foreground via the dock?
I think you are replying to a bot which knows absolutely nothing.
yeah I was wondering about that
Bots are a growing problem but we are working to solve it. For now, don't listen to people who are answering your question but there's a warning saying it's their first post.
