By Toji


2009-06-30 17:08:54 8 Comments

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.)

8 comments

@DaveInCaz 2017-06-16 12:49:18

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.

@Deanna 2016-08-11 11:45:38

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.

@UserX 2011-09-21 14:07:00

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

@Pillgram 2015-02-18 02:01:50

The example given is a common programming trap, where only the last item in the list is actually typed as declared all other types would be defaulted to Variants. It would not matter if you actually wanted variants, but if you did it with any other type you would get all variants and only the final item would get the declared type.

@sirboderafael 2017-11-09 02:12:35

Perfect! I have been struggling with this for days until you show how to solve it! Thanks!

@wqw 2009-07-03 06:40:01

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.

@Toji 2009-07-03 14:41:16

Thank you for your very detailed response! I'll have to discuss this with the other developers at my office and see if it's a workable solution for our situation.

@MarkJ 2009-07-04 17:24:04

This would make a good answer to the "VB6 IDE tip and tricks" question stackoverflow.com/questions/664370/…

@Simon D 2009-10-20 15:18:32

When I tried this it worked for enums (but then again so does somewhat simpler solution above), but not for methods or properties - they keep whatever case they have in the source code, and override the case of any nearby enums. Any idea what I might be doing wrong?

@wqw 2009-10-20 15:43:35

<quote>Since we already had a project-wide typelib we referenced from every project before anything other typelib</quote>. Notice the "before any other typelib" part. Move the fixup typelib as high as possible in References dialog, "before any other typelib".

@MarkJ 2009-06-30 21:43:38

I can sympathise. Luckily we're allowed to turn off case sensitivity in our version control diff tool!

It seems the VB6 IDE automatic case-correction occasionally changes case in variable declarations and references, perhaps depending on the order in which modules are listed in the VBP file? But the IDE doesn't tell you that the file needs to be saved. So the problem only shows up when you saved the file because of another edit. We briefly tried to prevent this by checking out all the files in a project and setting the case carefully, but it didn't go away.

I suppose you could list the variable names that are affected - the usual suspects are one letter names like "I", "X" and "Y", perhaps because they are used in standard event handlers like MouseDown. Then write an add-in that'll search for all declarations " As" and force the case to upper. Run the add-in on your modules before you check them in. You might be able to trigger the add-in to run automatically when you save in VB6.

EDIT: Something I've just thought of: adapt Fred's answer. From now on, every time you check in a file, add a block at the top to establish canonical case for the usual suspects. If nothing else, it's easier than reverting hundreds of lines by hand. Eventually you will have this block in every file & maybe then the problem will stop happening.

#If False Then
  Dim I, X, Y ' etc '
#End If

@Simon D 2009-06-30 17:17:10

Depending on your situation adding

#If False Then
    Dim CorrectCase
#End If

might help.

@curtisk 2009-06-30 17:18:40

what does that do exactly?

@Simon D 2009-06-30 17:22:41

Gives canonical case without creating a variable. Useful if enums are changing case.

@Lance Roberts 2009-06-30 17:28:19

Good solution for some cases.

@Toji 2009-06-30 17:36:17

Thanks for the answer, and I'm sure this would work great for some projects, but unfortunately I think the scale of our projects rules out this solution.

@Marcus Mangelsdorf 2016-01-27 14:52:50

Amazing! If you just messed up one casing accidentally this will fix it for good at least in the Office 2010 VBA Editor - Thank you!!!

@JP Alioto 2009-06-30 17:15:46

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. :)

@Miquella 2009-06-30 17:38:37

Yes, a variable naming policy does help some, it does not solve the problem. Third party libraries can wreck havoc on a naming policy, causing the case to change project wide, sending you straight back into the same cycle (as Toji stated in the reply to U62's answer).

@JP Alioto 2009-06-30 19:39:33

There is no "solution".

@Phil1970 2016-06-15 01:18:19

@Miquella Well, if a third party library does not follow Microsoft naming convention, then it does not deserve to be used... So a policy could be to ban such libraries.

@U62 2009-06-30 17:15:35

Wow. I've spent a lot of time programming in VB6 and I have no idea what you're on about. The only thing I can think you're referring to is that intellisense will change the capitalization of variable names to match their declarations. If you're complaining about that, I would have to wonder why the hell they've been entered any other way to begin with. And if that is your problem, no, there's no way to disable it that I'm aware of. I'd suggest you, in one go, check out every file, make sure the caps on the declarations and uses of variables all match and check back in.

@Tomalak 2009-06-30 17:24:32

Exactly. If anything, then the fellow developers are the ones changing the ^@#*ing variable casing. The VBA IDE just makes it consistent.

@Tomalak 2009-06-30 17:26:13

Wow, what a quick down-vote. Seems like someone does not like to see this answer at +1.

@Lance Roberts 2009-06-30 17:27:29

Guess you didn't read the question and see how large his project is, this answer is obviously completely unworkable in his situation.

@Tomalak 2009-06-30 17:31:56

@Lance Roberts: Obviously I'm from the "I have no idea what you are talking about" fraction. Which may be because I have (admittedly) never worked on a VB6 project of that size. So, when exactly does VB6 arbitrarily change variable name casing?

@Toji 2009-06-30 17:33:40

One major flaw with this is that several of the third party libraries we use have a different naming convention than our own code, causing the case to change matching the third party library or back to our own, depending on what order VB loads the files in. To make this even worse, some of the third party libraries use different naming conventions between them. This, in addition to problems like the enumeration casing rules (described in the link that curtisk provided) make case control in complex projects very difficult.

@Tomalak 2009-06-30 17:46:36

@Toji: I thought variable names are bound to the scope the variable is used in? How could the third party naming convention in a different module affect your own? I guess I'm just lacking experience here, but I genuinely don't get it.

@Toji 2009-06-30 18:06:03

I thought that originally as well, but we have seen evidence in our system of cross-module case changes occurring, and have heard other developers cite similar problems. If it truly was scoped to the current file it wouldn't be a problem, but unfortunately that's just not the case.

@Tomalak 2009-06-30 18:44:11

@Toji: I see. Thanks for explaining!

Related Questions

Sponsored Content

6 Answered Questions

[SOLVED] Is there a Visual Basic 6 decompiler?

  • 2009-01-05 18:38:52
  • Rismo
  • 123998 View
  • 45 Score
  • 6 Answer
  • Tags:   vb6 decompiling

4 Answered Questions

[SOLVED] Visual Basic 6.0 Case Statement

  • 2011-12-21 18:28:19
  • Joe Winfield
  • 90579 View
  • 12 Score
  • 4 Answer
  • Tags:   vb6

9 Answered Questions

[SOLVED] Difference between Visual Basic 6.0 and VBA

  • 2009-06-14 17:43:27
  • Thomas Geritzma
  • 171010 View
  • 203 Score
  • 9 Answer
  • Tags:   vba vb6

10 Answered Questions

[SOLVED] What does DIM stand for in Visual Basic and BASIC?

3 Answered Questions

[SOLVED] VB6: "Visual basic has stopped working"

  • 2016-03-28 10:32:23
  • anne
  • 7037 View
  • 1 Score
  • 3 Answer
  • Tags:   vb6

2 Answered Questions

[SOLVED] visual basic stop webService connection

  • 2015-04-15 08:39:41
  • Silvia Parfeni
  • 31 View
  • 1 Score
  • 2 Answer
  • Tags:   vb6

2 Answered Questions

[SOLVED] Git - Discard case only changes

3 Answered Questions

[SOLVED] VB6 Randomize function?

Sponsored Content