If public variables in different modules share the same name, it's possible to differentiate between them in code by referring to both the module and variable names. For example, if there is a public Integer variable intX declared in both Form1 and in Module1, you can refer to them as Module1.intX and Form1.intX to get the correct values.
To see how this works, insert two standard modules in a new project and draw three command buttons on a form.
One variable, intX, is declared in the first standard module, Module1. The Test procedure sets its value:
Public intX As Integer ' Declare Module1's intX.
Sub Test()
' Set the value for the intX variable in Module1.
intX = 1
End Sub
The second variable, which has the same name, intX, is declared in the second standard module, Module2. Again, a procedure named Test sets its value:
Public intX As Integer ' Declare Module2's intX.
Sub Test()
' Set the value for the intX variable in Module2.
intX = 2
End Sub
The third intX variable is declared in the form module. And again, a procedure named Test sets its value.
Public intX As Integer ' Declare the form's intX
' variable.
Sub Test()
' Set the value for the intX variable in the form.
intX = 3
End Sub
Each of the three command buttons' Click event procedures calls the appropriate Test procedure and uses MsgBox to display the values of the three variables.
Private Sub Command1_Click()
Module1.Test ' Calls Test in Module1.
MsgBox Module1.intX ' Displays Module1's intX.
End Sub
Private Sub Command2_Click()
Module2.Test ' Calls Test in Module2.
MsgBox Module2.intX ' Displays Module2's intX.
End Sub
Private Sub Command3_Click()
Test ' Calls Test in Form1.
MsgBox intX ' Displays Form1's intX.
End Sub
Run the application and click each of the three command buttons. You'll see the separate references to the three public variables. Notice in the third command button's Click event procedure, you don't need to specify Form1.Test when calling the form's Test procedure, or Form1.intX when calling the value of the form's Integer variable. If there are multiple procedures and variables with the same name, Visual Basic takes the value of the more local variable, which in this case, is the Form1 variable.
You can also have a variable with the same name at a different scope. For example, you could have a public variable named Temp and then, within a procedure, declare a local variable named Temp. References to the name Temp within the procedure would access the local variable; references to Temp outside the procedure would access the public variable. The module-level variable can be accessed from within the procedure by qualifying the variable with the module name.
Public Temp As Integer
Sub Test()
Dim Temp As Integer
Temp = 2 ' Temp has a value of 2.
MsgBox Form1.Temp ' Form1.Temp has a value of 1.
End Sub
Private Sub Form_Load()
Temp = 1 ' Set Form1.Temp to 1.
End Sub
Private Sub Command1_Click()
Test
End Sub
In general, when variables have the same name but different scope, the more local variable always shadows (that is, it is accessed in preference to) less local variables. So if you also had a procedure-level variable named Temp, it would shadow the public variable Temp within that module.
Due to the effect of shadowing, form properties, controls, constants, and procedures are treated as module-level variables in the form module. It is not legal to have a form property or control with the same name as a module-level variable, constant, user-defined type, or procedure because both are in the same scope.
Within the form module, local variables with the same names as controls on the form shadow the controls. You must qualify the control with a reference to the form or the Me keyword to set or get its value or any of its properties. For example:
Private Sub Form_Click ()
Dim Text1, BackColor
' Assume there is also a control on the form called
' Text1.
Text1 = "Variable" ' Variable shadows control.
Me.Text1 = "Control" ' Must qualify with Me to get
' control.
Text1.Top = 0 ' This causes an error!
Me.Text1.Top = 0 ' Must qualify with Me to get
' control.
BackColor = 0 ' Variable shadows property.
Me.BackColor = 0 ' Must qualify with Me to get
' form property.
End Sub
The names of your private module-level and public module-level variables can also conflict with the names of your procedures. A variable in the module cannot have the same name as any procedures or types defined in the module. It can, however, have the same name as public procedures, types, or variables defined in other modules. In this case, when the variable is accessed from another module, it must be qualified with the module name.
While the shadowing rules described above are not complex, shadowing can be confusing and lead to subtle bugs in your code; it is good programming practice to keep the names of your variables distinct from each other. In form modules, try to use variables names that are different from names of controls on those forms.