Wiki Update: Application Trigger (Issue)

Submitted for your review, comment, and/or revision, the following Wiki article has been updated:

Application Trigger

Primary Changes:

  1. Added table to clarify what type of Macro Group is needed for each app trigger type.


Running Keyboard Maestro 8.2.1 (8.2.1) on macOS 10.12.6

The text of the existing Wiki article is inconsistent with my testing. I just created a Macro to trigger on Excel activation, in a Macro Group available ONLY in Excel, and it fired when Excel launched.

EDIT: Just for grins, I duped the macro and put in BBEdit group, with BBEdit Activates Trigger. Same result.

The wiki states:

Caution: As with all triggers, the trigger will fire only if the Macro Group that contains it is active, which is based on the current foreground application before the specified application launches, or after the specified application is deactivated or quits. In practice, this means the Macro Groups that contain this trigger should be targeted at All Applications.

Be careful not to place macros with these triggers inside a macro group that is only active when the specified application is active. Otherwise, by the time the macro itself becomes active, the application has already launched and activated and so the macro will not fire.

My macro is very simple, but I will upload so you can see and test for yourself:

MACRO:   Test App Activation Trigger

~~~ VER: 1.0    2018-07-02 ~~~


Test App Activation Trigger.kmmacros (2.4 KB)
Note: This Macro was uploaded in a DISABLED state. You must enable before it can be triggered.


Macro Group


It might work for Activates, but it is very fragile. It does not work for Launches, Quits, or Deactivates.

As such, the trigger should not be restricted to only within the target application, it should be globally active. The trigger itself defines when the macro will first, rather than the macro group activation settings.

Technically, it would probably be ok for the macro group to be active both within the target application and within the previous or next application. But again, the behaviour would be quite fragile.

Hence, use the trigger in a macro that is active in all applications or you will likely get inconsistent results.

I don't understand the table in the wiki page.

Well, perhaps it should be removed.
Based on my testing (discussed above), I found that a trigger of "App Activates" need only be in a Group for that app. You say that's "very fragile". I don't know what that means. I have tested it quite a bit, as did another user, and it always works.

This process make sense to me:

  1. App A is not running: "App A Activates" macro is inactive.
  2. App A launches
  3. This causes App A to be active and front most: "App A Activates" macro is now active, and so it is triggered.

What am I missing?

Well, it is fragile in the semantics of the trigger do not mean anything if the macro is not active before and after the trigger might be required to fire.

So if the macro is not active both before and after the application Launches, then the Application Launches trigger might not fire - which happens first, the macro becomes active/inactive or the trigger fires? Semantically, it is not well defined, so it might change depending on who knows what (some subtle change I make, some change to the speed of your Mac, some other system change, who knows). That is what I mean by fragile - a macro that works today might stop working tomorrow.

The same analysis applies for Application Quits/Activates/Deactivates. The for ensured correct behaviour, the macro must be active both before and after the change that would trigger the macro.

And this includes cases like an application launch that induces and application activation, if the macro is triggered by Application Activates, then the macro should be active before the application launches. Similarly, for Application Deactivates and the application quitting.

So that pretty much means if the macro uses an Application trigger, it should be active always, or pretty close to it, but certainly more than just when the target application is running or active.

There is no guarantee that those things have in a strict sequential order. The macro activation might be delayed for a very brief time for example.

In theory, you are correct, the sequence should always be:

  1. An application launches.
  2. Any macros that are active when an application is running should become active.
  3. The application becomes active.
  4. Any macros that are active when an application is active should become active.

However Application Launch triggers might be processed with at 1.5 or 2.5, and Application Activation triggers might be processed at either 3.5 or 4.5. And which one might vary from time to time (even with no changes to your Mac configuration). That alone, even under the best of circumstances pretty much requires the macros to be globally active.

And in practice, 2 might actually happen after 3 or even after 4. There is no iron-clad guarantee that macro activation happens instantly, or that notification about such things as activation or launching happens serially, they tend to be sent as notifications and notifications can be received out of order.