Q129712: PRB: Capitalization in Visual Basic 4.0 Differs from 3.0

Article: Q129712
Product(s): Microsoft Visual Basic for Windows
Version(s): WINDOWS:4.0
Operating System(s): 
Keyword(s): 
Last Modified: 11-JAN-2001

-------------------------------------------------------------------------------
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 1986-2002.