But then the same page goes on to show these examples:
"For example, variables named “MyMacro__Text Message”, “Instance Text Message” or “Local Text Message” will all display the label “Text Message” in the form. The actual variable used will be the full variable name."
So, having the Prompt not display the the prefix works without having to use any underscores at all, if the Variable starts with Local or Instance in its name. LOCAL__Text works to hide the prefix and so does LOCAL Text or LOCALText
I have been adding two underscores to all my local Variable names but it looks like I didn't need to?
So basically, when making Local or Instance variables there is no need to have any underscores in the name to have the Prefix hidden. Putting "local" or "instance" as the prefix is enough. Certainly no need to have two underscores which is how I have always been making them...
With Global Variables it is different. They need the two underscores if the Prefix is to be hidden in a Prompt.
As most of my Variables are Local Variables I might consider how I name them in future. I tend to name AppleScript Variables something like varDate so from now on I might just name my Keyboard Maestro Local Variables something like locaDate or even local Date which is easier to read.
I stay away from spaces in variable names, as it's just one more possible thing that could go wrong when trying to use them in a shell script, AppleScript, etc.
Yes, it seems somehow wrong and dangerous to use spaces in the name. But in this case (in the context of how the Variable appears in the Prompt) I think it is often necessary to include spaces to make the Prompt work in a natural way. For example:
Yep, that's why I immediately reassign it after the input action—and because I never regularly use variables with spaces, it's very unlikely I'd use it accidentally.
Thanks for saving a thousand words, that quick visual saved some time and cleared things up with more tests than I would have thought to do. Thanks for the screen shot!
I was thinking the exact same thing so nice that this is here. I've used this before, but had to come back and be reminded how to do this.
"So, you can hide the prefix if the variable name starts with a prefix followed by two underscores."
"So, you can hide the prefix if the global variable name starts with a prefix followed by two underscores (the two underscores only apply to global variables)."
@peternlewis - Sorry to resurrect an old thread, but the Wiki says:
So, you can hide the prefix if the variable name starts with a prefix followed by two underscores. Then the label will show only the latter part of the variable name.
While this may be technically true depending on how you define "prefix", it's not how I wish it would work. I wanted my label to say "DND__DIP_ResourcesFolder", so I used the variable:
Local__DND__DIP_ResourcesFolder
And I got the label "DIP_ResourcesFolder". In other words, KM considered "Local__DND__" to be the prefix. I would have expected it to consider the prefix to be "Local__".
The same thing happens if I use "Local DND__DIP_ResourcesFolder".
Oh, interesting, so the Wiki is right that two underscores, no matter what, will be considered a prefix. Sounds like it is just looking at the last instance of double underscores and chopping everything before it.
That does look like a bug to me. It's as if the pattern matching is being “greedy” and grabbing all the double underlines that it can.
Just for fun… This works as expected:
Can you guess why?
Here is the answerThat variable, Local__DNDˍˍˍDIP_ResourcesFolder, does not in fact use two instances of the conventional underline character (U+005F) between "DND" and "DIP".
It actually uses three instances of “modifier letter low macron” (U+02CD).
I'm happy to change it - if there is some reasonable objective reason one way is better than the other, but I'm not sure there is.
If I look at the variable Local__DND__DIP_ResourcesFolder, then the logical place to split it would be the last __, so DIP ResourcesFolder is displayed.
Is there some compelling reason splitting at the first __ makes more sense?
