DOCUMENT:Q129712 11-JAN-2001 [vbwin] TITLE :PRB: Capitalization in Visual Basic 4.0 Differs from 3.0 PRODUCT :Microsoft Visual Basic for Windows PROD/VER:WINDOWS:4.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Visual Basic Standard Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Professional Edition, 32-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 16-bit, for Windows, version 4.0 - Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows, version 4.0 ------------------------------------------------------------------------------- SYMPTOMS ======== Variable case is persistent after the first reference of the variable has been set. CAUSE ===== This happens because Visual Basic maintains a single name table for the entire project where all names that are not case-sensitive are stored as a single entry. This forces all occurrences of the same name, regardless of where it is used (Sub procedure, parameter, dim, type, or whatever), to be treated the same. The names are based on where they are declared. The case of the name in the last Declare statement always wins. Each name is tagged in the name table with whether or not it has a corresponding Declare statement. If it does, any access to the name from a statement that is not a Declare statement causes the new name to have the same case as the name in the name table. STATUS ====== This behavior is by design. This design brings Visual Basic for Windows behavior more in line with the embedded version of Visual Basic, Applications Edition in Excel and other Microsoft products. MORE INFORMATION ================ Variable case in form files (.FRM) and modules (.BAS) in Visual Basic version 4.0 is handled differently from the way it was handled in version 3.0. In Visual Basic for Windows version 3.0, the case of your variables was decided by the most recent line parsed by the environment containing the variable. This behavior changed in Visual Basic version 4.0. When you first define a variable either by explicitly declaring it or implicitly by referencing the variable in a line that gets parsed (assuming Option Explicit is not enforced), that is the case that will be used throughout your program. This occurs for all variables in scope at the line where the variable name is referenced. Steps to Reproduce Behavior --------------------------- In Visual Basic version 3.0: 1. Start a new project in Visual Basic. Form1 is created by default. 2. Add the following code to the Form1_Click procedure: Dim MYVAR 'This creates a variable name in all Caps. myvar = 3 'This changes BOTH instances of the variable name to lower case. 3. Note that the following is the final result: Dim myvar myvar = 3 In Visual Basic version 4.0: 1. Start a new project in Visual Basic. Form1 is created by default. 2. Add the following code to the Form1_Click procedure: Dim MVAR 'This creates a variable name in all caps. MyVar = 3 'This variable name is changed to match the case of the original 'reference. 3. Note that the following is the final result: Dim MYVAR MYVAR = 3 Additional query words: 4.00 case sensitivity insensitive insensitivity vb4win vb4all ====================================================================== Keywords : Technology : kbVBSearch kbAudDeveloper kbVB400Search kbVB400 kbVB16bitSearch Version : WINDOWS:4.0 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.