5.3. Working with the Object Model

Regardless of the particular object model with which you're working and the application you're developing, the same issues tend to arise: how to create a new instance of an object, how to navigate downward from a parent to a child object, and how to move up the object hierarchy from a child to its parent object. In this section, we'll take a look at these and other issues.

5.3.1. Externally Createable Objects

Before you can start to work with your OLE automation server application, you must first create an instance of it. To do this, you must first know at what level the objects within the application can be created—that is, which objects allow the use of the New keyword.

Many OLE automation servers only allow you to use the New keyword with the top-level object, like Word.Application. However, other OLE automation servers, such as Microsoft Active Data Objects (ADO), allow you to create instances of objects much further down the object hierarchy. The statement-completion feature of Visual Basic helps you here. After you have typed the New keyword, a drop down list is displayed containing only those objects that are externally createable.

So if you can't directly create an instance of the required object, how do you obtain a reference to it? First, create an instance of an externally createable object higher up the hierarchy; then use the prescribed method or property to create an instance of the required object. For example:

Dim oXLapp As Excel.Application
Dim oXLwsh As Excel.Worksheet
Dim oXLhyp As Excel.Hyperlinks
    
Set oXLapp = New Excel.Application
Set oXLwsh = oXLapp.Worksheets.Add
Set oXLhyp = oXLwsh.Hyperlinks.Add

In the above snippet, your goal is to create a reference to an Excel Hyperlink object. However, you can't simply create a new Hyperlink object. You have to create the Application object first, then a Worksheet object, then finally the Hyperlink object.

For details of how you can restrict the creation of your own classes written in VB, see Section 4.5.3 in Chapter 4.

5.3.2. Navigating Through the Object Model

You can think of the object model as a road map. To get from town A to town B, you can't simply drive across fields, through forests and rivers to get to your destination. You must take designated highways, and you leave the highway at the most convenient interchange and take a minor road to the place you are going. The same is true of an object hierarchy. You must use the paths laid down by the designer of the object model to navigate from one level of the hierarchy to the next, and so on. And just like a road system, there is often more than one route to get to the same place, but one may be quicker and more efficient than another.

5.3.2.1. Objects returned by properties

One of the most common ways to obtain a reference to an object on the next level down in an object model hierarchy is through a property that returns an object. For example, a property of Excel's Worksheet object is Cells, which in fact returns a Range object. You must therefore understand what type of object is returned by a particular property or method in order to declare a local object variable of the correct type. For example:

Dim oXLapp As Excel.Application
Dim oXLwsh As Excel.Worksheet
Dim oXLrng As Excel.Range
    
Set oXLapp = New Excel.Application
Set oXLwsh = oXLapp.Worksheets.Add
Set oXLrng = oXLwsh.Cells

5.3.2.2. Navigating up through the object model

There are many occasions when you are working with a particular object and need to call a method or property belonging to an object directly above it in the hierarchy. For this purpose, most object hierarchies provide you with a means of navigating back up the object model. This not only saves time when coding, but it's much more efficient at runtime. While the implementation is different in each object model, you should be on the lookout for properties called Parent, Window, Application, or Top. These are the properties that return a reference to objects further up the hierarchy.