Stop Visual Basic 6 from changing my casing

Question

Very simple question that is apparently impossible to find a decent answer to: How can I make Visual Basic 6 stop changing my ^@#*ing variable casing!?!

I know that the general opinion of a great many VB users is that this "feature" is actually quite helpful, but I doubt that they use it much with any source control system. This is absolutely INFURIATING when you are trying to collaborate on a project of any significant size with several other developers. If ignored, you produce thousands of false-positive "changes" to your files (even ones with no actual code changes!) that pollute the revision history and make it near impossible in some cases to locate the actual change that took place.

If you don't ignore it (like my office, where we have been forced to implement a "no unneeded case change" policy), you spend 5x the time you would normally on each commit because you have to carefully revert out VB's "corrections" on every file, sometimes reverting hundreds of lines to put in a one line change.

Surely there must be a setting, plugin, hack, etc. out there that can remove this unwanted "feature"? I am willing to take any method I can get as long as it doesn't require me to pick through piles of phantom diffs. And to squash a couple of complaints up front: No, I can't turn off case detection in my diff tool, that's not the point. No, we can't just make the case changes globally. We're working with hundreds of thousands of LOC being worked on by multiple developers spanning many years of development. Synchronizing that is not feasible from a business standpoint. And, finally: No, we cannot upgrade to VB.net or port to another language (as much as I would love to).

(And yes, I am just a tiny bit peeved at the moment. Can you tell? My apologies, but this is costing me time and my company money, and I don't find that acceptable.)

Answer 1

Depending on your situation adding

#If False Then     Dim CorrectCase #End If 

might help.

Answer 2

Here is a real world scenario and how we solved it for our 350k LOC VB6 project.

We are using Janus Grid and at some point all the code lines which referenced DefaultValue property of JSColumn turned to defaultValue. This was an opportunity to debug the whole IDE nuisance.

What I found was that a reference to MSXML has just been added and now the IDE picks up ISchemaAttributes' defaultValue property before the Janus Grid typelib.

After some experiments I found out that the IDE collects "registered" identifiers in the following order:

• Referenced Libraries/Projects from Project->References in the order they are listed

• Controls from Project->Components (in unknown order)

• Source Code

So the simple fix we did was to create a dummy class/interface with methods that hold our proper casing. Since we already had a project-wide typelib we referenced from every project before anything other typelib, this was painless to do.

Here is part of the IDL for our IUcsVbIntellisenseFix interface:

[   odl,   uuid(<<guid_here>>),   version(1.0),   dual,   nonextensible,   oleautomation ] interface IUcsVbIntellisenseFix : IDispatch {     [id(1)] HRESULT DefaultValue();     [id(2)] HRESULT Selector();     [id(3)] HRESULT Standalone();     ... } 

We added a lot of methods to IUcsVbIntellisenseFix, some of them named after enum items we used to misspell and whatever we wanted to fix. The same can be done with a simple VB class in a common library (ActiveX DLL) that's referenced from every project.

This way our source code at some point converged to proper casing because upon check-out the IDE actually fixed the casing as per IUcsVbIntellisenseFix casing. Now we can't misspell enums, methods or properties even if we try to.