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

Answer 1

Specifically for controlling the case of enum values, there is a VB6 IDE add-in which may be helpful. Enums seem to have a slightly unique version of this problem.

As described in the link below:

The VB6 IDE has an annoying quirk when it comes to the case of Enum members. Unlike with other identifiers, the IDE doesn't enforce the case of an Enum member as it was declared in the Enum block. That occasionally causes an Enum member that was manually written to lose its original case, unless a coder typed it carefully enough. ...

However, if a project contains a lot of Enums and/or a particular Enum has a lot of members, redeclaring the members in each of them can get quite tedious fast. ...

Ref: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums

...load and unload the add-in as needed via the Add-In Manager dialog box. Usage is as simple as selecting the entire Enum block, right-clicking and then choosing the "Lock Enum Case" context menu item.

Answer 2

I have a similar problem:

in a bas module there I wrote :

Private sub bla_bla()
  Dim K as integer
End Sub

so in a class module the Dim k as integer will automatically be replaced by IDE become 'Dim K as integer' <-- it's not logical but then: I correct the bas module become:

Private sub bla_bla()
  Dim k as integer
End Sub

then magically the problem in the class module was solved (still be k and not automatically replaced by IDE become K). Sorry I'm poor in English

Answer 3

I don't think there's any to do it. The IDE will change the case of the variable name to whatever it is when it's declared. But, honestly, back in the day I worked on several large VB6 projects and never found this to be a problem. Why are people on your development team constantly changing variable declarations? It seems like you have not established a clear variable naming policy that you enforce. I know your upset, so no offense, but it might be your policies that are lacking in this regard.

Unfortunately, according to this SO thread, alternate VB6 IDEs are hard to come by. So, your best bet is to solve this problem via policy. Or move to VB.NET. :)

Answer 4

SIMPLE WAY: Dim each variable in the case that you want. Otherwise, VBA will change it in a way that is not understandable.

Dim x, X1, X2, y, Yy  as variant

in a subroutine will change ALL cases to those in the Dim statement

Answer 5

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.

Answer 6

I standardised the case across the codebase, normally by using the examples above (Dim CorrectCase), and removing it again. I then triggered VB to save EVERY file, by doing a case sensitive search/replace of "End" with "End" (no functional change, but enough to get VB to resave). Once that was done, I could then do a single commit to standardise the case, making it MUCH easier to keep on top of it at a later date.