Forum Discussion
Access changing lettercase - redux
This has probably been beaten to death, but I'm fuming, so here goes. I want Microsoft to DO SOMETHING to help.
Access has the highly annoying habit of changing lettercase on identifiers, seemingly at random. This is a real pain when using add-ins like MSAccessVCS, which makes it possible to use git for source code control.
Here' what I've deduced is happening:
- There exists a dictionary/symbol-table containing every identifier used in a project.
- The symbol table contains ALL identifiers, including those defined by MSAccess, referenced libraries, and your code.
- Searching that table is case-insensitive, but it stores the canonical version of the identifier with case preserved.
- Normally, when you type an identifier that already exists in the table, the VBA editor "corrects" the lettercase of your entry to match the table's entry.
The extremely annoying part is that sometimes that last step works in reverse.
You type an existing identifier, but with a different lettercase. Instead of correcting what you typed to match the table, it instead updates the table with the version you typed, and decides that's the way future and existing identifiers should be spelled.
Here's a recent example. I tried to create a class module constructor (Class_Initialize) but typed it "class_initialize" implicitly expecting that the VBA editor would "fix" it. Instead, it updated the symbol table and set the canonical lettercase to the all-lowercase version... and then proceeded to change the lettercase on the Class_Initialize() method in all my class modules. It has now decided the canonical lettercase is "class_initialize" and that's what it "corrects" to from now on.
Of course, when I did the next MSAccessVCS export, git showed a bunch of unwanted (but cosmetic) changes. This pollutes the changeset and makes source control more difficult.
THIS. IS. A. BUG.
My workaround is, when starting a checkin, I go through the list of changes and group all such changes into one commit called "VBA Artifacts". But come on, this shouldn't be necessary.
At least let us know WHY this happens, and give us some control of the process. A way to specify/correct the canonical casing would help.
8 Replies
Here's what's going on. This is informed by my having gotten my start on Dartmouth Basic in the late 60's and realizing that the basic (pun intended) operation of tokenization hasn't changed in almost 60 years, at least in VBA.
- Your BASIC statements are compiled to a tokenized intermediate representation that is easy to interpret. This happens every time you "commit" a statement by pressing ENTER or moving the cursor away from the line. In the tokenized form, names are stored as references into a symbol table.
- There is one (and only one) symbol table (i.e. namespace) where ALL names are stored.
- A symbol table entry contains a case-sensitive spelling of every name. However, when the table is searched, the comparisons are case-insensitive.
- There can be many objects with the same (case-insensitive) name, in different scopes, but only a single entry in the table for a given name, and that entry contains the current case-sensitive canonical spelling of the name.
- When you enter a statement that "creates" a name (Dim, Sub, Function, Const, etc) the canonical spelling in the symbol table gets updated to the spelling you just typed. If you accidentally type a name that differs only in lettercase from an existing name, the symbol table gets updated with the new spelling.
So this explains how the symbol table gets updated. The next bit explains why this affects names in seemingly unrelated places.
The crucial point is that what you see in the editor is not the code that you typed
- Remember that every time you enter a statement it gets tokenized to binary opcode(s) and symbol table references. What you typed is actually discarded (except for comments).
- As soon a statement is committed and tokenized, the process is reversed and the VBA source code version of the statement is recreated. As part of that process, any names are retrieved from the symbol table.
So, committing a "name-creating" statement updates the symbol table with the current letter-case spelling of the name. This seems to trigger a global "decompile" step that updates all existing statements that refer to the changed name, which immediately affects any open code windows.
Whenever you perform any operation that involves displaying source code (open a code module, export source), the VBA source gets regenerated from the stored tokenized version, using the current letter casing from the symbol table. So changing spelling on one place affects all references to that name.
To "fix" what you perceive as broken lettercasing for a specific name, all you have to do is "commit" a "name-creating" statement with the correct letter case. It makes no difference what that statement is, even a simple Dim will work.
So, back to my example:
- I inadvertently typed Sub class_initialize(). Since this is a "name-creating" statement, the symbol table was updated to make the canonical spelling all lower-case.
- All other instances of Class_Initialize() were changed to lower-case
- To fix it, all I had to do was enter Dim Class_Initialize as Long, commit the statement, and then delete it.
Problem solved.
For information.
The Access team at Microsoft does not own VBA. VBA is owned by the VBA team.
While it is highly annoying that this name changing behavior occurs in VBA when used in Access, it's not directly an "Access" problem. I suspect that developers using Excel, Word, et al are equally annoyed when it happens.
But ultimately, the complaints need to be directed to the responsible team to have a chance of being addressed.OK, so I posted my feedback using the "official" channel, the Feedback function in Access.
It got posted to Access, not VBA.
So the question remains: How does one post feedback that will reach the VBA team?
Hi,
Two weeks ago at my DevCon conference Mike Wolfe asked the Microsoft Access team (not for the first time) if they can do anything about it. --> No cure in sight. You can read more about it in his blog post.
Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEKAny chance to fix by Recompile Database?
Decompiling and recompiling your Access database can resolve symbol table inconsistencies. Use the /Decompile command-line option to clean up your project.
As I noted in my reply above, de/re-compiling won't fix things until you force the symbol table to contain the correct spelling.
