Event queue snafu - breaking a death spiral

I have a macro that mistakenly calls itself. Didn't start out that way, it used to work fine, but maybe some accidental change of a key press action or trigger. The macro would activate an app (Camtasia, call it C) then did a keypress for C which somehow happened to be the macro's trigger. I ended up with a never-ending series of prompt windows.
WHAT DIDN'T WORK: Edited the macro to change the prompt text, removed the trigger, disabled the macro, disabled the group, logged out and back in, and even rebooted, the old macro (with the OLD prompt text which didn't exist any more) kept returning with its infuriating prompt window.

SOLUTION: . Long story short, I moved C to the trash. Then I could OK my way out of the dialog windows. Then move C back. All was well after that. But BOY what a mess for a while.

I'm perplexed how doing all those things didn't stop the macro from triggering. My guess is that you had a duplicate copy of the macro (either in the same macro group or a different group.)

However there's one thing that everyone should keep in mind. Removing a trigger, deactivating a group, disabling a macro, or even editing the macro(!!) won't stop any existing instance copy of a macro from running if it's already running. (This may not have been your issue, but I'm mentioning it because many people do have this issue.) So everyone should have a macro that performs a "stop all running macros" action, and I recommend placing it in your "Global Macro Group." Like I have here... (I use this macro about 50 times per day.)

Another thing that can help is to open the KM Engine's Debugger. While this can be opened using the mouse over the KM Engine's menu bar icon, sometimes I write macros that accidentally move the mouse in an infinite loop, so assigning a keyboard shortcut helps me out, like this... (I use this macro about 20 times per day.)

There's a third, even more desperate option, which should never be used because it can cause corruption (although I use it five times per day for a year and it has never caused corruption for me.) I won't provide the code because people will say it's "too dangerous," but I will describe it to you anyway. It is a shortcut in the macOS Shortcut apps, which toggles the engine (either stops it, or restarts it if it isn't running.) I placed the Shorctuts menu bar item directly next to the KM Engine menu bar, like this: (the restart engine shortcut is safe, it's the Toggle shortcut that unsafely terminates the engine.)

Screenshot 2024-05-12 at 04.43.00

The reason I have this utility is that sometimes the KM Engine becomes either sluggish or completely non-responsive, so my method uses an external method to kill it. This is probably "my fault," because I use a lot of KM macros in infinite loops that are doing OCR actions or Find Image actions, which is probably a far higher workload than the KM Engine was ever designed to do.

1 Like

I don't know exactly what your Shortcut does, but there's a KM-approved method that might do—roughly—the same thing without the risk? From the plug-in actions Wiki page:

In normal use, once a plug in action is read, it will stay in memory and changes will not be noticed (although the script will be executed each time, so changes to that will be noticed). To cause the editor and/or engine to notice changes to the plug while in development, use AppleScript to reload the macros:
ă…¤
tell application "Keyboard Maestro" to reload
tell application "Keyboard Maestro Engine" to reload

The one difference is that this doesn't toggle the state, it simply reloads the engine. But maybe it's worth testing as a simple compiled AppleScript app to see if could replace your Shortcut?

-rob.

That method does NOT free up gigabytes of RAM that the KM Engine tends to consume for me.

Gotcha; was worth a shot :).

-rob.

The AppleScript "reload" for both KM and the Engine applies to just macros - not the executables themselves.

Take a butcher's at this thread:

1 Like