Object Variable Scope
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
When you create a new instance of a class and assign it to an object variable, that instance exists in memory until the object variable goes out of scope, or until you explicitly set it to Nothing in your code. This is an important issue to consider when designing custom objects, because it is easy to leave objects lying around in memory, tying up resources unnecessarily.
The scope of an object variable depends on where you have declared it. If you declare it in the Declarations section of a standard module, it exists from the time code begins running in the project until the project is reset or the file containing the project is closed. If you declare it within a procedure, it exists until the procedure has finished executing. If you declare it in the Declarations section of a class module, it exists for the lifetime of an instance of that class.
When creating a hierarchical object model, you typically want top-level objects or collections to have a global scope, so you should declare the object variables to represent them as public module-level variables in a standard module. That way the object variables will be available throughout the project for the lifetime of the project. Of course, you have to assign to them an instance of a class before you can use them.
If your object model includes an object or collection that belongs to another object or collection, you'll want the lower-level object to exist only after the higher-level object has been created. For example, each ParentWindow object in the ParentWindows collection represents an open application window in the system. Each ParentWindow object has a collection of ChildWindow objects that contains the child windows belonging to the ParentWindow object, if there are any. Because you do not know what window a ChildWindow object will represent until you have created its parent, and because you might have several different collections of ChildWindow objects, you do not want to declare the object variable for the ChildWindows collection globally. Instead, declare a private module-level object variable to represent the ChildWindows collection within the ParentWindow class module. Each instance of the ParentWindow class can then maintain its own ChildWindows collection.
If your project includes objects that do not form an object model, you might simply want to create an instance of the class locally within a procedure, as you require it. In that case, it makes sense to create the System object variable within the procedure that requires it, and destroy it as soon as you are finished using it.
As with any other variable, you should try to scope object variables that point to custom objects as narrowly as possible to optimize performance and to reduce the risk of bugs that might be introduced by having to manage global variables.
See Also
Why Build Your Own Objects? | Basic Class Concepts | Creating Property Procedures | Creating Events and Event Procedures | Extending Objects Through Interfaces | Designing Object Models | Creating Custom Objects for Web Pages