Code Modules, Object Modules, and Scoping

There seems to be a significant amount of confusion between Object Modules (Forms, Reports, and Classes), and Standard Code Modules, especially with respect to Public/Private scope, and terminology in general.

Forms, Reports, and Classes are Objects, whereas Standard Code Modules are not. That makes all the difference with respect to scoping, and correct terminology in general.

LetÆs look at the Objects. These include Forms, Reports, and Classes. Objects have Properties, Methods, and Events. They really donÆt have Subs and Functions; they have Methods, some which do not return values, some of which do. It is unfortunate that VBA uses the keywords Sub and Function to distinguish between those Methods that do return values and those that donÆt, as that significantly adds to the confusion. Items declared in the declarations section of an object are not variables; they are Properties of the object. Using Private in the declarations section of an object creates a Private Property of the object. Using Public in the declarations section create a Public Property of the object.

Properties and Methods can either be Public or Private, but in the case of Objects, this is NOT defining scope, but rather indicating whether or not the Property/Method can be exposed outside of the Object. Everything defined inside of an object has as its defined scope, the Object, and only the Object.

If a property has been defined as Public, then it can be referenced from outside the Object, but only with a fully qualified Object reference. This is absolutely necessary. Consider the case where youÆve defined a Form, and inside that Form, youÆve declared a Public Property call OpMode. LetÆs also say that youÆve instantiated five copies of that Form Object. If OpMode really were public or global, how would the system know which OpMode you were interested in? There would be five of them, one for each copy of the Form. That is obviously not the case, and the reason is because none of the OpMode properties have scope outside of the Form in which declared, therefore, the system wonÆt find any of them. But since the Form is an Object, and Property is Public, you can, with a fully qualified Object Reference to identify the specific instance of the Form, access a specific instance of OpMode.

Remember that Forms, Reports, and Classes are objects, and operate as described above.

Lets contrast that with a Standard Code Module. A Code Module is not an object, which means that it has Variables, Subroutines, and Functions. There can only be one copy of any of these because you cannot create additional copies of a Code Module, because it is not an object. Because a Code Module is not an object, then the Public/Private designation does define scope. A public variable declared in the declarations section of a code module has Public/Global scope to the entire application, or is private to the module in which itÆs declared. There is no possible ambiguity because there can be only one copy of that variable. Similarly for the Subroutines and Function. Those declared as Private are limited in scope to the module in which they are defined, and those that are Public have global scope and are available to the entire Application.

So where do you declare a Global Variable? The only possible place is in the declarations section of a Standard Code Module.

To avoid confusion, when you speak of modules, you should identify the type of module, be it a Form Module, a Report Module, a Class Module, or a Code Module so that we all can understand the Scoping rules that are in effect.