Access lettercase random changes

[jhgarrison]

I've posted a rant about this ongoing problem in the MS Tech Community forum

Access changing lettercase - redux

It might be useful if other users of msaccess-vcs could add some weight to this.

[josef-poetzl]

Fitting the problem: #599

In general:
The Access team is in the process of integrating version management again. Unfortunately, this team is not responsible for VBA or the VBE. It would be a good combination to get to grips with the problem mentioned with version management. ;-)

[jhgarrison]

#599 is curious: I'm not sure sanitization is the way to go since it can't be 100% foolproof unless it has access to a complete syntax tree matching what the VBA compiler has. Does it?

In my latest run-in with Access it decided, for no reason I can fathom, that when I typed class_initialize(), with other Class_Initialize() methods already in existence, that the all-lowercase version was now the canonical spelling and changed all the other ones. I don't know how many times VB has changed X to x and then back again a few days later.

If only MS would share the algorithm that makes these decisions then we'd know what not to do. or even better, how to get things back to where we want them to be. @josef-poetzl any chance we can get that?

[josef-poetzl]

If only MS would share the algorithm that makes these decisions then we'd know what not to do. or even better, how to get things back to where we want them to be. @josef-poetzl any chance we can get that?

I use the add-in prototype to compare all function names and variables with the option of restoring the “previous” lettercase.
The check and correction can take place before the export if you open the form for comparison as a dialog.

See Video (Youtube): Dictionary add-in meets MSAccessVCS

[mwolfe02]

@jhgarrison As far as I know, I've written the most thorough description of the VBA IDE algorithm for this "feature": VBA's Case Changing "Feature"

As for the "sanitization" I proposed in #599, it is every bit as simplistic as the VBA IDE feature it's attempting to provide a workaround for. It's an 80/20 solution that would have the practical effect of severely limiting the knock-on effect of case changes by preventing export of Access objects that only differ from previous exports based on case changes. I've been using a form of this for nearly 15 years in my own homegrown Access version control solution. I proposed it as an enhancement to the project because it's the single biggest thing I miss in VCS addin vs. my own solution.

Your example is a perfect use case. When you manually changed the casing of the Class_Initialize() method, it would have updated every single other class module in your project that included that method. Let's assume you have 10 class modules with that method. Let's further assume you are only actively editing one of those class modules. When you made that one innocent change, it would have resulted in 10 file changes appearing in Git. However, only one of those files contains real changes.

My proposed solution would be to export the code exactly as it is (without messing with the letter casing in any way). However, when creating a checksum of the file, the addin would first convert the file contents to all upper or lower case only for the purposes of creating the checksum. For performance, vcs-addin file exports compare file checksums rather than file contents when deciding whether an object has changed for exporting purposes (you also have the option to force a full export of all files).

The proposed solution is modest both in its implementation complexity (just lower-case the contents of a file before creating its checksum) and in its destructiveness (or lack thereof) (the exported files are not impacted in any way--only the creation of the checksum which has the follow-on effect of limiting the number of objects exported...and, hence, the number of false positive file matches).

[jhgarrison]

That sounds dangerous to me. The file has changed but the change isn't exported... what if it's a change you want, such as, in my case, if Access decides to "re-correct" class_initialize back to Class_Initialize? And anyway, all it does is kick the can down the road until the next full export, at which point you'll have many more case-change artifacts mixed in with your real code changes. Yes, git gui or other such tools can pull out changesets, but that's still a manual process, and the onus is still on us.

The real solution needs to happen in the VB editor, with access to the symbol table and a repeatable way to force a particular spelling when Access screws it up.

I got started with Dartmouth Basic on a GE-635 in the late 60s. I understand that the internal representation is some form of interpreted bytecode instructions (I know that's Java, I forget what they were called back then). Each line you enter is compiled to bytecode, and the source code you see is back-formed from the bytecode as soon as you enter it.
So the process is this:

• You enter a line of VBA code that includes one or more identifiers and "close" the line (i.e. move the cursor away)
• The compiler parses the line and generates bytecode, looking up any identifiers it finds
• For a given identifier, if the identifier doesn't exist in the symbol table it is added; otherwise it is looked up
• In either case the reference to the symbol table entry is stored in the interpreter bytecode
• Finally, the source code displayed for that line is back-generated from the bytecode, and THAT is what gets displayed

You think the code you typed in is yours. It's not. It's been generated back from the compiled bytecode. Then, in all lines referencing a given identifier, if the symbol table entry changes, the back-generated source code for ALL those lines changes as well. Note that this will happen only when the compiler decides it needs to re-generate the displayed source code, which may or may not happen immediately, but will happen pretty soon.

This is how the compiler knows to "correct" a mis-cased identifier. For some reason, it sometimes decides to update the symbol table with the new version instead. Why this happens is a mystery... although as I type this I'm sensing it might have to do with naming a new instance of some some object class (Sub, Function, Class, Enum, etc) vs just referencing an existing object.

Hmm... I'll have to play with this a bit.

[jhgarrison]

OK, I figured it out, I was right.

TL;DR: When you type in a statement that, when executed, will cause instantiation of a new object, the letter case you use for the name of the identifier associated with that object becomes the canonical version. If that identifier name already exists (case-_in_sensitive), this will override the spelling of that identifier name wherever it appears in your entire project regardless of scope or context.

I'm not saying the innards work exactly like this, only that to an outside observer it behaves as if the following are true:

• The VBA code is stored as bytecodes, and the displayed source is generated from the bytecode. Identifier names are retrieved from the symbol table when the human-readable code is generated.
• The symbol table's primary key is a case-insensitive version of the identifier
• The symbol table contains the "canonical" spelling of the identifier with regard to case.
• Since there are many scopes in which a name can appear, there is a sub-entry chained off each identifier's entry, for each distinct object instance with that name existing anywhere in the project. A sub-entry contains things like scope, type, etc., whatever is needed in that object's definition within its scope.
• If you merely refer to an existing object, say in an expression, the current canonical spelling gets immediately substituted as soon as you "commit" the statement. This is the "oh, it fixed my letter case correctly" situation.
• When you type in a statement that has the potential to create a new object, if the name already exists (case-insensitive), the name you type becomes the new canonical (case-sensitive) spelling.
• Since in the bytecode there are no names, only references to the symbol table, Access will substitute the current canonical spelling when displaying the "source", wherever that identifier occurs. In some instances this happens immediately, in others it will happen whenever Access has to re-generate the VBA source from the bytecode.

I'm still working through all places where a new object instance can be created, but it includes:

• Any form of Dim (i.e. includes Public, Private, Const, Static)
• Sub or Function
• Formal parameter definition in Sub or Function
• Property
• I'm sure there are others I haven't covered

Knowing this, it's easy to mess with even VBA's naming for form event procedures.

1. Create a blank form and add a command button (it will be named Command0)
2. Add an on-click handler. VBA will name this Command0_Click
3. Create an empty module and add a method Command0_click
4. Go back to the form's module and you'll see the method name is now the lowercase version.

So the simple fix if VBA messes with your identifier name is to just type Dim [the correct letter cased name] as [anything] and then rebuild the project.