3.8. Object Variables and Binding
Although Object variables are in many ways no different from other types of variables, the fact that they are references to other software components rather than simple values warrants special attention. While objects, classes, and binding are discussed in greater depth in Chapter 4, a short introduction to the subject is nevertheless worthwhile.
3.8.1. Declaring Object Variables
Object variables are declared in much the same way as other variables. There are three ways to declare an object variable:
Dim myObject As LibName.ClassName Dim myObject As New LibName.ClassName Dim myObject As Object
In each of the methods shown above, a Private or Public statement can replace the Dim statement, and the same scope rules apply as for other variables.
In the first declaration, the object variable is referenced to the class type library, but no instance of the class is assigned to the variable. At this stage, myObject is set to Nothing. To reference the class in this manner, you must have used the References dialog to add a reference to the class to your project. To assign a reference to a real instance of the class, you must use the Set statement prior to using the variable; for example:
Set myObject = LibName.ClassName
This produces an early bound reference to the object.
In the second declaration, a reference to a new instance of the class is assigned to the object variable, which is now ready to use immediately. Again, to reference the class in this manner, you must have first used the References dialog to add a reference to the class to your project. This second method also produces an early bound reference to the object; however, the object isn't actually created until the object variable is used.
In the third declaration, the object variable has been declared as a generic Object data type. This is useful when you don't know beforehand what type of object you will be creating. At this stage, the object variable also has a value of Nothing; to assign an object reference to it, you must use either the CreateObject or GetObject functions. An object variable declared in this manner is said to be late bound.
3.8.2. Early and Late Binding: Performance Comparisons
Whenever you read about when and why to use early binding and late binding, the choice always seems unambiguous: late binding is less efficient than early binding. But this isn't always the case; there are a number of factors to consider when choosing a method of object binding.
First, does the object to which you are binding execute within the same process as the client, or does it run in its own process? Will it be running on the same machine or on a remote server? In general terms, late binding is slightly more efficient for out-of-process ActiveX EXEs, and early binding is vastly more efficient for in-process DLLs.
A second factor that affects the relative performance of late and early binding is the operating system. The differences between late and early binding appear to be magnified on Windows 95, whereas they are less noticeable under Windows NT 4.0. You may also find variations if your DLL is running through Microsoft Transaction Server.
In short, you should always bear in mind that efficient communication between software components takes careful planning and testing. You should be prepared to create test projects to experiment with the various options and to assess their performance.
In the same way that you should carefully consider how to handle your Object variables, the same performance considerations come into play when you are deciding how to pass variables between procedures and software components.
3.8.3. The Collection Object
VBA features one generic object type, the Collection object, which is simply a container for data. Although typically its members are other objects, it can in fact hold data of any type, including other collection objects. The collection object is therefore an object-oriented version of the Visual Basic array. It supports the following four methods:
Add
Adds an item to the collection. Along with the data itself, you can specify a key value by which the member can be retrieved from the collection.
Count
Item
Retrieves a member from the collection either by its index (or ordinal position in the collection) or by its key (assuming that one was provided when the item was added to the collection).
Remove
Deletes a member from the collection either by its index or its key.
For example, the following code fragment defines a collection object, colStates, to hold U.S. state information, and adds two members to it that can later be accessed by their key, which in this case happens to be their two-letter state code:
Dim colStates As New Collection colStates.Add "New York", "NY" colStates.Add "Michigan", "MI"
As we've noted, collection objects, like arrays, are containers for data. Like the elements in arrays, the members of collections can be iterated using the For Each...Next construct. And like arrays, they are accessible by their index value, although the lower bound of a collection object's index is always 1, and can't be set otherwise in code. But given the similarity to arrays, why use collection objects, rather than arrays, in your code? The major reason is ease of access and ease of maintenance:
Members can be added before or after an existing member based on the latter's key value as well as its index value.
Members can be retrieved based on either their key value or their index value.
Members can be deleted based on either their key value or their index value. Multiple deletions based on an index value, however, should be done backwards, from higher index values to lower ones, since the collection is reindexed after each deletion.