45

I'm not much of a Visual Basic person, but I am tasked with maintaining an old VB6 app. Whenever I check out a file, the editor will replace a bunch of the uppercase variable names with lowercase automatically. How can I make this stop!? I don't want to have to change them all back, and it's a pain to have these changes show up in SourceSafe "Differences" when I'm trying to locate the REAL differences.

It is changing it automatically in the definition, too: Dim C as Control becomes Dim c as Control. Dim X& becomes Dim x&. But it doesn't do it all the time; for example, three lines down from Dim x&, there's a Dim Y&, uppercase, which it did not change. Why's it do this to me?

TAbdiukov
  • 1,185
  • 3
  • 12
  • 25
Laure
  • 531
  • 1
  • 6
  • 11
  • Possible duplicate of [Stop Visual Basic 6 from changing my casing](https://stackoverflow.com/questions/1064858/stop-visual-basic-6-from-changing-my-casing) – StayOnTarget Jun 16 '17 at 12:49

10 Answers10

33

Since I always find this thread first looking for a solution to messed-up casing, here is one Simon D proposed in a related question:

If you just need to fix one variable's casing (e.g. you accidentally made a cOrrectCAse variable and now they are all over the place), you can correct this for good by adding

#If False Then
    Dim CorrectCase
#End If

to the beginning of your module. If you save the project and remove the statement later, the casing remains correct.

Using Excel VBA I often accidentally change all Range.Row to Range.row by carelessly dimming a row variable inside some function - with the help of Simon D's solution I can fix this now.

Community
  • 1
  • 1
Marcus Mangelsdorf
  • 2,852
  • 1
  • 30
  • 40
27

Continuing from DJ's answer...

And it won't only change the case of variables in the same scope either.

It will change the case of all variables with the same name in your entire project. So even if they're declared in uppercase in one place, another module might have different variables using the same variable names in lowercase, causing all variables in your project to change to lowercase, depending on which of the declarations was loaded (?) or edited last.

So the reason your C and X variables are changing case, while the Y isn't, is probably because C and X are declared somewhere else in your project too, but in lowercase, while Y isn't.

There's another mention of it here, where they mostly seem concerned with such variable names conflicting when case is being used to differentiate local from global variables. They end up going for prefixes instead.

The only alternative I can think of is to use some other editor with VB6-highlighting capabilities to do your editing...

Community
  • 1
  • 1
mercator
  • 28,290
  • 8
  • 63
  • 72
  • 2
    Just found an answer in: https://stackoverflow.com/questions/1064858/stop-visual-basic-6-from-changing-my-casing Look at the answer starting with "SIMPLE WAY" from "UserX"... I will paste here the answer: 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 – herrera Nov 09 '17 at 02:15
  • Sirboderafael's comment and Marcus Mangelsdorf's answer provide the real solution. In my case I had at one point in the past Dim'ed a variable called workbooks and VBA forever was changing Excel.Workbooks to Excel.workbooks, even after I had changed the original Dim statement to use another name for the variable. So in response to all the solutions suggesting I find the erroneous Dim and change it, I could not, because the Dim no longer existed but VBA wouldn't let it go. Temporarily Dim'ing a variable called Workbooks solved the problem... and VBA should be shot in the head and buried. – Opsimath Nov 30 '18 at 18:58
7

Enums are even worse. Getting the case wrong anywhere the enum is used changes the case of the definition.

John Y
  • 354
  • 2
  • 8
4

To get past the painful file diff experience, set the VSS option in the diff dialog to do case-insensitive comparisons. That way you'll only see the "real" changes.

Matt Dillard
  • 14,677
  • 7
  • 51
  • 61
0

Close all the VB projects, open the form file with a text editor, change the case of all the names then re-open the Project with VB IDE.

Perception
  • 79,279
  • 19
  • 185
  • 195
0

It must be defined/declared in lower-case. Locate the declaration and fix it there. The IDE will always change the case to match the declaration.

DJ.
  • 16,045
  • 3
  • 42
  • 46
  • 8
    -1 Untrue. VB6 changes name casing as it pleases, regardless of scope and explicit definitions. Just as others have said. No point going to the definition and fixing it here. It will just break some other definition in different scope. It's pretty random, depending on which files were touched last. – Tomek Szpakowicz Mar 27 '09 at 18:54
  • 1
    -1. Not always true. If you have a team working with version control on the same project, VB6 does sometimes change name casing when you check in. It changes the declaration *and* the usages for its own reasons. Never figured out what triggers it to do it. – MarkJ Jun 30 '09 at 21:23
0

Prevent VB6 auto correct For enum values

As my general rule I declare constants in UPPERCASE. Since enums are essentially constants I like to declare values for enums in UPPERCASE as well. I noticed the VB6 IDE also auto corrects these.

I found the IDE does not correct these values when using numbers and underscores '_' in the value names.

Example:

Public Enum myEnum
  VALUE      'Will be corrected to: Value
  VALUE1     'Will not be corrected
  VALUE_     'Will not be corrected
End Enum   

I do not know if this works in general and if this extends to naming/auto correction of variable names.

Marko
  • 39
  • 3
0

I have had a similar enumeration problem where for no apparent reason UPPERCASE was changed to MixedCase.

Enum eRowDepths
    BD = 1
    CF = 1
    Separator = 1
    Header = 3
    subTotal = 2
End Enum

When I changed to the following (tailing the last character of the non-conforming variables), I had no problem

Enum eRowDepths
    BD = 1
    CF = 1
    SEPARATO = 1
    HEADE = 3
    SUBTOTA = 2
End Enum

It turns out that this is a case of the tail wagging the dog. I have the following code, not the most elegant I admit but working nonetheless (please excuse formatting issues):-

'insert 3 rows
  iSubTotalPlaceHolder = i      
  rows(ActiveSheet.Range(rangeDMirrorSubTotals).Cells.Count +  _
                                                        Header _
                                                         & ":" _
      & ActiveSheet.Range(rangeDMirrorSubTotals).Cells.Count + _
                                                      Header + _
                                                    subTotal + _
                                           Separator).Insert

So it seems that the compiler won't accept explicit UpperCase constants as part of this statement.

This was acceptable

Dim fred as Integer
fred = SEPARATO + HEADE + SUBTOTA

So my work-around is to use a variable instead of the constants as part of the complex insert statement if I want to stick to the rule of keeping enumerated constants uppercase.

I hope this is of use

TAbdiukov
  • 1,185
  • 3
  • 12
  • 25
-2

DJ is spot on... VB always changes the case of variables to match the original declaration. It's a 'feature'.

Neil Albrock
  • 1,035
  • 10
  • 16
  • 2
    If you have the same variable name declared in multiple scopes, but with different casing, it will change *all* of them back and force depending on which file you edited last. – Scott Whitlock Jun 25 '10 at 11:03
-2

Continuing from Mercator's excellent answer...

I'd recommend:

  1. Check out all files (I assume you're using VSS for a VB6 app)
  2. Do a rebuild of the entire project group
  3. Recheck back into VSS

Now base you're the real differences rather than the 'auto' changes that VB6 has tried to apply.

Andrew Bickerton
  • 468
  • 4
  • 14
  • So your solution is: Let it change everything as it wants (meaning: randomly) and live with it? Great! Sorry. I'm just working with code merged from several projects with differing naming conventions. My (otherwise small) checkins are mostly a noise of random changes in name casing. I've had enough! – Tomek Szpakowicz Mar 27 '09 at 19:01
  • 1
    yes that is my recommendation, VB is trying to change the case of your variables for a reason (not 'randomly'), if you want to see only what you have changed AND you want to use Visual Studio to do it, create a baseline first. – Andrew Bickerton Mar 31 '09 at 16:41
  • Or use a different editor, but if you open it in Visual Studio later on you're in the same position. – Andrew Bickerton Mar 31 '09 at 16:42
  • By 'randomly' I mean whichever version it sees first it imposes on all other occurences, regardless of type, scope, etc. So either your resulting casing is random or you'll have to inspect all names and fix them by hand to have this 'baseline'. As if VB6 forms weren't a pain to merge without this. – Tomek Szpakowicz Apr 09 '09 at 09:31
  • Problem with this method is that it only resaves the files with the changed case if you actually edit the file. So between steps 1 and 2, you'd have to make some minor edit to every file (in the IDE) and save them all. – Scott Whitlock Jun 25 '10 at 11:02
  • 3
    Anyone using VSS for *anything* needs their head examining. – Adrian Jul 26 '13 at 20:40