Problems setting variables

I'm having problems setting variables to the clipboard contents.
Using the debugger I know that the system clipboard is getting the right values, but then they don't get transferred to the variables. So, when I run this macro the variables are always empty

I must be missing something very simple

Because you saving the first result back to the clipboard you are changing the clipboard so, when you run the second filter it is looking at that new changed clipboard instead of the words you originally copied.

Instead of saving the results back to the clipboard and then to variables, you can save the results directly to variables and not change the contents of the clipboard:

Word & Character Count.kmmacros (4.0 KB)

@Zabobon thank you for your reply. The first macro I tried was just like yours but did not include LOCAL__ in the variable names. So, I removed LOCAL__ from your macro and it no longer worked.

I went back and read this manual page and it seems I was using "global" variables.

I can see that there's no need for a global variable that persists on my computer, but why doesn't it work?

I find the explanation about variable scope to be confusing. My guess is always use "local" in front of my variable names now, But can you clarify?

It's not a scoping issue (though it's always good to limit scope whenever possible).

Your Filter actions are set to take the contents of the clipboard, do something, then put the result back on the clipboard. So your first replaces the words on the clipboard with a number, your second then counts the characters in that number.

If you look at @Zabobon's macro you'll see that his Filter actions act on the clipboard contents but output to variables, leaving the clipboard as it was.

1 Like

If you were working with my Macro when you made the name change to the Variables my guess would be that you didn't also update the text in the final Display Text dialog at the end of the Macro.

So, you would need to change:

To:

I believe I did exactly what you said and it doesn't work for me. Here is a screen recording showing it working and then not working once I remove the LOCAL__ in front of each variable name. What am I missing?
m

It might be as simple as you are testing the new Macro too quickly after making the edits. Keyboard Maestro needs a bit of time to catch up when you make changes to Variable names.

There is nothing wrong with the way you have edited it.

Your response made no sense to me because I had tried this many times with the same result. I usually figure that if I try a macro 5 or more times and it keeps failing that the macro itself must be wrong.

Nevertheless, I tried the macro again after receiving your post (which was 20 minutes after making it and it still didn't work. So I figured you must be wrong.

However, I then restarted my Mac and found the macro worked. So maybe you are right. How long do I need to wait? Hours?

This sort of thing does not inspire confidence.

It's possible the Keyboard Maestro Engine somehow got hung up (it happens on rare occasions). In the future, try using the File > Quit Engine then the File > Launch Engine menu items in the Keyboard Maestro Editor—that should usually fix any issues.

-rob.

Okay, I will do this -- if it works my confidence will be re-inspired...

This is yet another reason to not use global variables unless you have to -- for persistence across separate executions or to pass data between macros, for example.

Okay, I'm converted.

I will be using "local" all the time now in front of my variable names.

How do I clear out any sinful past?

First update your macros to use only local (or possibly instance) variables. Then open KM's settings, and select Variables. Anything listed there is a global variable; delete any you aren't still needing as globals.

The Variables page explains the differences well; local will be all you need most of the time, but instance can be very useful if you have macros that call sub-macros.

-rob.

I wish all my transgressions were so easily solved. I now have a clean slate:
cleanSlate

1 Like

...unless other types are more appropriate.

Right tool for the job at hand, and all that.

Just be more careful from now on. You've hit a real edge case here, with "empty" globals from your first attempts not taking (or not returning) the new values for some reason. Mostly globals do behave as expected, and you more at risk of unexpected "interference" by other macros than anything.

So while @griffman's right and you should change everything now, if you've a lot of macros using a lot of globals then take a more pragmatic approach and update them to use locals when you go back to them for (the inevitable) tweaking.

2 Likes