1

I have just started having this issue today with VS2012 and TFS.

We have our VB6 classes stored in Team Foundation Server.

I checked out a (VB6 *.cls) class for edit (in VS2012 TFS), then edited it in the Visual Basic 6 IDE, changing no more than 20 lines out of about 8900 lines in the class, before saving the class.

Unfortunately, when I try to compare my changes with the Latest version in TFS, I am getting hundreds of changes because either Visual Studio or TFS is changing all the Adodb. to 'ADODB.' as in the below picture

enter image description here

This makes it very difficult for my colleagues to review my code changes, as there should be no more than about 20....

EDIT: It looks like it is VB6 doing all these changes...

What do I need to change to fix this?

Our Man in Bananas
  • 5,809
  • 21
  • 91
  • 148
  • 1
    TFS doesn't change anything. That would defeat the purpose of it being a source control tool. – Daniel Mann Jan 03 '17 at 17:46
  • Within the changes you made was adodb altered to ADODB by any chance? There is standard behaviour for the VB6 IDE if a variable name is not defined. Admittedly you would have to try had to achieve this but maybe if you only checked out the .cls and opened it outside the context of the project you would lose the reference to the full ADODB class definition and then if you innocently edited the case of the ADODB prefix you would find the VB IDE would slavishly change every matching string to the same case. This is by design and illustrates why editing an individual file of a VB6 project is bad. – Vanquished Wombat Jan 03 '17 at 19:30
  • 1
    @VanquishedWombat: no, nothing like that... I only added code to an existing function - in the VB6 IDE – Our Man in Bananas Jan 03 '17 at 22:30
  • @OurManInBananas - Ok thanks for correcting me. – Vanquished Wombat Jan 04 '17 at 00:06
  • 3
    I'm not sure if this question is really a duplicate, but there is plenty of more information here: http://stackoverflow.com/questions/1064858/stop-visual-basic-6-from-changing-my-casing – StayOnTarget Jan 04 '17 at 11:35

1 Answers1

5

This is not a TFS issue. VB6 does this when it thinks the declaration of an object or variable has changed it's case-spelling.

But you can address this in TFS. Configure TFS to use an external compare tool, such as Beyond Compare or WinMerge (there are lots of others) that support case insensitive comparisons.

MarkL
  • 1,721
  • 1
  • 11
  • 22
  • Vote up from me. But whilst what you say is true, if the OP edited the file outside the project context then he certainly did not test it and all kinds of trouble could have been created by missing a simple ctrl-F5 run test. Not good practice. – Vanquished Wombat Jan 03 '17 at 19:32
  • 3
    @VanquishedWombat - I've seen this behavior from vb6 frequently, that is, referenced object types getting fully capitalized or vice-versa. Never bothered to try and figure out why/when/how vb6 decides to do this. I fully expect that the OP was editing in the vb6 IDE with the full project loaded, not outside of it. – MarkL Jan 03 '17 at 21:37
  • Agree it is unlikely but I've not seen VB6 IDE re-cap a variable that it knew about - only those when entering new code and referring to as-yet un-dimmed variables. Lets see what the OP says. Happy if my assumptions are incorrect. – Vanquished Wombat Jan 03 '17 at 22:08
  • 1
    @VanquishedWombat: it does compile, no issues with running a make of the dll – Our Man in Bananas Jan 03 '17 at 22:34
  • @OurManInBananas Ok thanks for correcting me again. Knew you were a pro. – Vanquished Wombat Jan 04 '17 at 00:07
  • This is a common problem with VB6. I also use WinMerge with case-sensitivity turned off. – StayOnTarget Jan 04 '17 at 11:34
  • 2
    This is indeed a well-known problem with VB6 as discussed [in this question](http://stackoverflow.com/questions/1064858/stop-visual-basic-6-from-changing-my-casing). There is a [workaround](http://stackoverflow.com/a/1078018/15639) to prevent this happening but it involves some work. It's very easy to do case-insensitive comparisons instead. – MarkJ Jan 04 '17 at 13:18