KM 10 - Easy Global Variable Clean-Up

EDIT: Between Peter disavowing this method, and reports from @DanThomas and @cdthomer that using it in macros with custom HTML prompts can result in global variables outside the macro's scope being deleted, I can no longer endorse it. Original post included for posterity below.

Thanks to KM 10's new %AccessedVariables% token, we now have a much easier way to erase any global variables our macros may use. Just add this action to the end of any macro with global variables you would like to clean up when the macro is done:

Easy Global Variable Clean-Up.kmactions (1.1 KB)

I recommend saving it as a favorite so you can easily add it to any macro you like.


That's a great idea. I wish to add that if you put that code inside an IF statement that looks like this, then it will execute the cleanup operation only if the CAPS LOCK button is activated. This will give the user a little control over if/when the cleanup happens. The user can clear variables at the end of any macro when the CAPS LOCK button is depressed. Nobody uses the CAPS LOCK for anything anyway. It's the most useless key that ever existed.


1 Like

Nobody uses the CAPS LOCK for anything anyway.

You might be wrong there; several people use that key as a Hyper key

(I do)


I use it all the time for its intended purpose...

1 Like

I use it all the time for its intended purpose...

So do I.


You might be wrong there; several people use that key as a Hyper key…

But now I purchased a Stream Deck XL and noticed it has a KM plug-in!

So many new opportunities…

Just came across this and I like it. I just downloaded it to try it out.

Currently I use an AppleScript to delete all my debug_ variables, but occasionally it only deletes about %90 of them. @DanThomas said he experiences the same thing whether he uses AppleScript or JXA so it's not just me apparently.

This might be a more reliable way to cleanup variables. Thanks again for sharing!


1 Like

No question about it.

The token knows what variable were used in the macro, and there's no parsing involved.

Yes, I think this is a great idea.

I'm curious, though, if it ever ends up having the same issue of some variables not going away, even though you set them to %Delete%?

If it does solve the problem, I want to know why. Because the other way of doing it (deleting variables with a prefix) does actually set all the variables to %Delete% - it's just that sometimes, some of the variables refuse to go away. So like I said, if this new method never has that problem, I want to know why. Because, you know, curiosity and/or WTF?! :grinning_face_with_smiling_eyes:

I hope that makes sense.

Hey Dan,

Setting a variable's value to nothing or to %Delete% will cause it to be unavailable to AppleScript:

tell application "Keyboard Maestro Engine"
   exists of variable "winList"
end tell

However – setting to nothing will leave the variable visible in the Keyboard Maestro variables preference panel.

The AppleScript above will return false in both cases.

I just ran my delete variables script.

set pinnedVariableList to {}

tell application "Keyboard Maestro Engine"
   set varNameList to name of variables
   # set varValueList to value of variables
   repeat with varName in varNameList
      if varName is not in pinnedVariableList and varName does not start with ¬
         "DND_" and varName does not start with "ENV_" then
            setvariable varName to "%Delete%"
         end try
      end if
   end repeat
end tell

Here's the the seeming result in the KME's variables panel:

However – if I run this script:

tell application "Keyboard Maestro Engine"
   name of variables
end tell

My result is:


Just for giggles I'm going to set the variables to something like "NULL", before I set them to "%Delete%" and see if it make a difference to the display.

I rate this as a bug, but I'm not absolutely certain it is one...



Hey Chris, what's the purpose of these two lines?

It appears that it checks to see if a variable is in a "pinned list" and if it is does not delete it. Is that correct?

I've known about this for a long time. I know I "spoke" with Peter about it, maybe 5 years ago, but I don't recall what he said, other than ever since then, I just shrug my shoulders and say "whatever".

1 Like


That's so I can add specific variables to the pinned list to keep them from being deleted.

That's how I used to handle all variables I wanted to keep, until someone came up with the “DND_” prefix years ago.


That was Jim.


How do you add a variable to that pinned list?

I’m interested because I have certain global variables that I use during work or other things but don’t need them once I’m done. So I don’t necessarily need them to be DND_ prefixed variables since I do eventually delete them.

Ok so I just tried this in an extremely simple macro that consisted of setting three variables, and then deleting them.

It was a disaster.

I have no idea what happened but it wiped out a LOT of my global variables... including some of my DND variables. I have NO idea how it happened... I can post the macro here if you want to see it...

@cdthomer and @ccstone:

It just dawned on me that using %AccessedVariables% to delete "unwanted" variables might be a horrible idea, at least until @peternlewis changes something.

This may not explain @cdthomer's situation, but it's important anyway.

I'm gonna start off talking about a Custom HTML Prompt, but stick with me here, because I think this may extend beyond just the prompt.

A week or two ago, I discovered that if I ran my Variable Inspector Prompt (custom HTML prompt) twice in one macro, the second time %AccessedVariables% returned ALL KM variables.

When you run a Custom HTML Prompt, KM puts ALL KM variables in "document.kmvar". I believe that when KM does this, it is inadvertently marking every variable as having been accessed by the macro. I think Peter agrees with me here, but I won't speak for him.

So if you were to use the "Easy Global Variable Clean-Up" macro after running a Custom HTML Prompt, you'd probably delete all your variables.

So that's bad as it is. But I'm wondering if other things may inadvertently affect %AccessedVariables% that we don't know about.

So beware.


Thanks for this info Dan. It sounds like what happened to me because initially I had run your VIP just before the "delete" action... which might explain why it nuked dang near my entire variable list :laughing:


Yeah, yeah, blame it on me. :laughing:

So now I'm thinking I should add a warning to the post for VIP. What do you think?

@gglick I don't know if you've been following along, but if not, read my post above. How do you think we should handle this? (And if you need more explanation, let me know.)

Well yea man, I can't be held responsible for my actions... that's ludicrous! :laughing:

It might be a good idea, at least until Peter confirms or denies what your suspicions are about it.