KM 10 - Easy Global Variable Clean-Up

Correct.

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.

-Chris

That was Jim.

3 Likes

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.

2 Likes

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:

-Chris

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.

3 Likes

It's not a bug, it is just a consequence of there being lots of different ways of listing variables, and they get different results depending on the method due to their different utility.

The only guaranteed way for a variable to "exist" is for it to have a non-empty value that is not “%Delete%”.

Every other case varies depending on its use.

A variable will be stored in the database if and only if it is non-empty.

A variable will be listed in AppleScript if and only if it is in the database and not “%Delete%”.

A variable will be listed in the Preferences (or in a variables menu) if and only if it is in the database and not “%Delete%” or it is used in any macro.

Different lists have different purposes and so get different results.

2 Likes

Using the %AccessedVariables% to delete variables seems a risky idea at best.

A variable could be accessed for any number of reasons, and in this case, any use of the Custom HTML Prompt counts as accessing all variables (as it could in theory mean since they are implicitly accessed, just like they are in any other script execution).

2 Likes

Does Disabling a macro hide the global variables in this macro? If yes, things will be easy. I use version number to track down how does a KM macro grow up.
For example, I have
This Macro v1
This Macro v2
This Macro v2.1
This Macro v3
This Macro v4
This Macro v5
...
This Macro v16
This Macro v17
This Macro v18
Only The newest one - This Macro v18 is enabled. All others is disabled.
Note in This Macro v1-v17, there is a global variable called thisGlobalVar.
But from This Macro v18, I decide to change its name to thatGlobalVar.
But I found thisGlobalVar keep existing in Preference.
I need to go into each one of This Macro v1-v17. Change the varname one by one. But there is no meaning to do this. Because they are history version.
If I disable a macro, it looks like they are still alive in some way.

Global variables persist until they are removed via an action setting that variable to %Delete% or deleted via the preferences menu. However, any macro that has them will recreate them if it is ran. So you could delete the older variables and they should reappear in the preferences menu unless you execute the older macros.

For a more tidy version history you could export those older versions and keep them in a folder on your computer that way they don’t take up space in the KM plist file and the Editor app.

I know i can do this. But I really want to keep these history versions in KM. They are like annual ring of tree. They are full of meaning and you can go back to any one any time. They are life. You can see how a method was developed. They are even the most important thing in KM. I really don't want to keep them out of KM.

1 Like

Haha I know what you mean, I love looking back at earlier macros too.

You can always import them again when you want to look through them. This way you don’t bloat the plist file but you can still review them when needed.

But to go back to the earlier question... as long as you don’t execute those macros again, any variables they contain will not be recreated.

You could move them all into a dictionary. The "key" would be the name of the variable, and the "value" would of course be the variable's value. That way you'd have them in one place, and could clear out the variables themselves.

Yes. I ll try. Dictionary is new thing to me.
But actually it doesn't change the way how does disable work.
And another strange thing about Disabled macro is that actually you can execute a disabled macro in Execute a Macro action.
You can try. This is true.
You disable a macro, but you still can call this macro in other macro. It's a little a bit not logical.

1 Like

Global variables don't belong to any macro - that's what makes them global. As for being able to execute a disabled macro, I always thought this was strange too, but whatever...

2 Likes

Yes - I raised this ages ago (see the discussion in this thread)

It still perplexes me, too!

2 Likes

It is odd. And particularly for the Macros using the new "Subroutine" Trigger. If a Macro's only trigger is to be executed as Subroutine and that Macro is disabled I would expect it not to run. But enabling or disabling Subroutine Macros makes no difference - they can always be executed when called.

However, there is a plus side to this behaviour in that disabled Macros do not show in Palettes but can still be executed as Subroutines and not clutter up the Group Palette (or be clicked on by mistake in the Palette).

1 Like

I had not explored this “feature” with subroutines - so that’s good to know: thanks!

Indeed and I’ve employed this property several times myself. It is quite handy actually.

1 Like