Case changes in variable names no longer working?

In earlier versions of SD, one could change the case of letters within a variable name (being sure to change all occurrences of the name) and get the changes to stick by just recompiling. Not sure when this stopped working, but it’s now failing for me.

I even tried changing all occurrences of a variable name to something completely different (xyzzy), recompiling, then changing the names back with the desired case changes. Upon recompiling again, the original variable name is restored with the original letter casing.

Is this happening to anyone else, or is it unique to my world?

Stan C.

– OS X 10.11.6 (15G1217), Debugger 6.0.4 (6A198)

You should be able to change the case in a variable’s name (assuming Script Debugger 6) – what matters is the case used for the first instance of the variable the compiler comes across.

There’s an expert preference that can turn this off. To turn it on, run this script:

use AppleScript version "2.4" 
use framework "Foundation"

current application's NSUserDefaults's standardUserDefaults()'s setObject:true forKey:"PrefResetIdentifiersOnCompile"

Edited to fix the boolean

Hi Shane,

I tried the expert script (with the boolean fix), but it didn’t help. I’m also seeing other bizarre behavior.

Here’s an example (this follows a fresh reboot while holding cmd-opt-P-R):

  1. Open a new script window, delete my usual boilerplate text, and paste in a small script with a display dialog.
  2. Save as a script applet to the Desktop, then close it.
  3. Run the applet—no dialog appears.
  4. Drag the applet icon onto SD icon to open—the pasted text is gone and the boilerplate is back.
  5. When I look at the resources in the applet, I find:
    a. /Contents/Resources/Scripts/main.scpt contains the boilerplate text.
    b. /Contents/Resources/Scripts/main.recover.rtf contains the pasted script text.

It makes me wonder if my copy of SD or a prefs file is corrupt. Can I just drag the SD app to the trash and pull a new copy from the .dmg? Are there any preference or other files I should also drag to the trash? I don’t mind reentering registration info, resetting preferences, adding key shortcuts, etc.

Thanks,
Stan C.

The app itself is very unlikely to be corrupt, but you could try deleting the prefs file. Reboot and delete it before launching SD.

Yes, dumping the prefs has fixed both (1) variable case changing and (2) retention of the correct code within a saved applet.

Many thanks for the help, Shane.

Stan C.

Are there some variable that are “reserved” and case is fixed?

I can change SixDAysAgo to SixDaysAgo without any problem.

But FileName and fileName both change to filename (all lower case) in EVERY script I code them.

FileInfo changes to fileInfo (lower case f, upper case I). So it’s like certain variables can change but others cannot. Doesn’t matter if it’s the first variable in the script or not. I’ve made the entire script text, changed ALL occurrrences of the variable to the case I want, and re-compiled the script from the text version and the case still goes back to the unwanted form.

Any suggestions?

Jim Brandt

Do the scripts use script libraries?

Yes. I guess the implication is that the variables are defined in a script library?

That’s right. That’s why use statements are important with libraries that use AppleScriptObjC: they tend to be case-sensitive, so their terminology should be loaded first.

Thanks, Shane. That wasn’t obvious to me. Now I’ll know where to focus when changes don’t happen as I expect.

One thing to keep in mind is that Cocoa has rules for what case the first character of a name is: for variables and methods it should be lowercase (except where the first word would normally be uppercase), and for class names, enums and constants it should be uppercase. The uppercase ones usually have a prefix, like NS.

This basically means you’re less likely to see changes happening if start variable names with lowercase letters.

And if you’re not happy with one, you can always use pipes to force things.