PRB: Naming Conflicts Between Variables and ObjectsLast reviewed: September 29, 1997Article ID: Q129898 |
The information in this article applies to:
SYMPTOMSConflicts between the names of various constructs produce errors in Visual Basic version 4.0.
CAUSEProblems of this type are caused by not taking into account the scope of variables and objects. When a conflict occurs, Visual Basic gives precedence to constructs of a narrower scope over those of a broader scope. Some cases of this type can be handled by Visual Basic's design time syntax checker, but others must be handled later (called late binding) in order to permit more versatility.
RESOLUTIONUse unique names for variables, objects, and other constructs whenever possible. When this is not possible, such as with type libraries, specify a fully qualified name (for example, OpenDialog.Help_Button) to avoid potential conflicts.
STATUSThis behavior is by design.
MORE INFORMATION
VariablesVariables have three possible levels of scope: local, module, and global. If two variables of the same name are defined, Visual Basic uses the variable of the narrowest scope. Therefore, by using unique names for local variables, you can avoid a problem.
Type and Object LibrariesMultiple type libraries may use the same name but give different values. The ShowHelp flag of the Common Dialog control has different values for each type of dialog that uses it. Attempting to refer to just ShowHelp produces the diagnostic "Ambiguous name detected" at run time. To avoid conflicts, specify the fully qualified name of the construct, such as FileOpenConstants.ShowHelp. The "Ambiguous name detected" topic in the Help file describes the following other ways this message can be produced:
Form and Module NamesUsing the name of an internal function as the name of a Module, such as String.BAS, produces no diagnostic in the IDE. Attempting to run the program with references to the String$() functions produces the following diagnostic:
Expected variable or procedures, not moduleBecause Visual Basic considers the module definition to be of narrower scope than the internal function, it attempts to call the module as a function. Specifying the function as VBA.String$() resolves the issue, but selecting a different module name is the better option. Keywords : PrgOther VB4ALL VB4WIN vbwin GnrlVb kbprg Technology : kbvba Version : WINDOWS:4.0 Platform : WINDOWS Issue type : kbprb |
================================================================================
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |