Here are five tips about "wildcard triggers." Writing this message has forced me to think about these features so they will be easier for me to remember.
-
The "typed string" trigger accepts wildcards. you just have to change the option from "case must match" to "regular expression match". Then you can use a wildcard character, such as a dot (".") which will match any alphabetic character. Or you can use other kinds of wildcard characters like "\d" which matches any digit, and which I use in Example 1, below.
-
The Hotkey trigger does not directly support wildcard triggers inside the hotkey field (shown below) but you can simulate wildcards here by having multiple hotkey triggers for the same macro and using the %TriggerValue% token to determine in your code which hotkey was pressed. You will need to create multiple copies of the following trigger in the same macro. Check how I process the triggers in Example 2, below.
-
The USB Device Key trigger does not directly support wildcard triggers inside the USB device key field, but you can simulate wildcards here by doing the same things as described for hotkeys, above. There is one extra step here that you may want to do: in order to extract the name of the USB device key, you may want to remove the first character of the %TriggerValue% token which contains a special character. See Example 3, below.
-
The Application trigger does directly support a generic wildcard. By "generic" I means it supports a simple "asterisk" wildcard value, not a full regular expression. Example 4, below, is an interesting way to do something with that wildcard.
-
The "Mounted Volume trigger", "Wireless Network trigger" and "USB Device trigger" also support true wildcard triggers. Not many people will need these wildcard triggers, but I just came up with a really interesting and useful macro example that takes advantage of this. See Example 5, below.
Wildcard triggers are very powerful. Now for some examples:
EXAMPLE #1 - Typed String Wildcard Trigger
This little macro will put square brackets around any "function key string" that you type, and also replace the "F" with "Fn" which is an abbreviation for "function." It might not be something that most people need, but it illustrates the methods. Notice how you need to use %TriggerValue% to get the string that "triggered" the macro and then use a substring action to extract just the number of the user's typed string.
EXAMPLE #2 - Hotkey (Simulated) Wildcards
This example macro will speak out the name of any specified hot keys and also send that hotkey to the currently active application. Notice how it can perform different actions based on the name of the hardware key that was found in the %TriggerValue% token. Perhaps I should write a follow-up post explaining how to get those special characters used in this macro.
EXAMPLE #3 - USB Device Key (Simulated) Wildcards
This sample macro will send you a notification screen on your Mac when any of your Stream Deck buttons are pressed (from R1C1 to R2C2 in this example.) I find this to be extremely useful because when I use a Stream Deck device, I want to be able to shuffle the buttons to different positions, which is not easy to do when you hard-code a specific button to a specific macro. So using this method, I can pass the name of the Stream Deck button to a secondary macro which can then take whatever action it wants, knowing the name (eg, "R1C1") of the button that pressed it. Without this technique, I would need 32 separate macros, one for each button. So now I have a macro with 32 triggers which does nothing but pass the name of the button to a single Stream Deck button handler that I have. Everyone who uses a Stream Deck should be using this approach.
EXAMPLE #4 - Application Wildcard
This example will speak the name of any application that is activated. Notice how I extract the base name out of the full application name. You could also place this code inside a Switch or If action so that, for example, certain common apps not have their name announced when the app is activated. Another thing you might want to do is log the fact that an app became active using the KM Log action and passing the name of the app to that action. This could be very useful when examining the KM Engine's log file to debug your macros.
EXAMPLE #5 - Logging Any Device Connections
This simple example will log all network, device and volume connections in your KM Engine Log. With a little more work you could also log any disconnections, but for most people connections will be enough. What an interesting macro! I think I'll store it in my Global Macros Group as a permanent addition. Note that this may require the KM Engine having the necessary macOS permissions, otherwise the macro won't get triggered.
