| Microsoft Office 2000/Visual Basic Programmer's Guide | |
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's easy to leave objects lying around in memory, tying up resources unnecessarily.
The scope of an object variable depends on where you've 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.
For example, the ParentWindows collection is the top-level object in the EnumWindows.xls sample file, which is available in the ODETools\V9\Samples\OPG\Samples\CH10 subfolder on the Office 2000 Developer CD-ROM. The object variable that represents the ParentWindows collection is declared at the module level in a standard module, so that the variable is available to all procedures in the project as soon as code in the project begins running.
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. Since you don't know what window a ChildWindow object will represent until you've created its parent, and since you may have several different collections of ChildWindow objects, you don't 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 don't form an object model, you may simply want to create an instance of the class locally within a procedure, as you need it. For example, the System object in the System.xls sample file, which is available in the ODETools\V9\Samples\OPG\Samples\CH10 subfolder on the Office 2000 Developer CD-ROM, is an object that you may only use once in a while within a procedure to return the path to the Windows folder. 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're finished using it.
As with any other variable, you should try to scope object variables that point to custom objects as narrowly as possible in order to optimize performance and to reduce the risk of bugs that may be introduced by having to manage global variables.
For more information about designing an object model, see "Designing Object Models" later in this chapter.