What Are Objects and Object Models?
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.
An application fundamentally consists of two things: content and functionality. Content refers to the information within an application, that is, the documents, worksheets, tables, or slides and the information they contain. Content also refers to information about the attributes of individual elements in that application, such as the size of a window, the color of a graphic, or the font size of a word. Functionality refers to all the ways you can work with the content in the application, for example, opening, closing, adding, deleting, sending, copying, pasting, editing, or formatting the content in the application.
The content and functionality that make up an application are represented to the Visual Basic language as discrete units called objects. For the most part, the set of objects exposed by an application to Visual Basic corresponds to all the objects that you can work with by using the application's user interface. You should already be familiar with many of these objects, such as Access databases, tables, queries, forms, and reports; Excel workbooks, worksheets, and cell ranges; Word documents, sections, paragraphs, sentences, and words; Microsoft Outlook messages, appointments, and contacts; Microsoft PowerPoint presentations and slides; and FrontPage-based webs and pages.
In some cases, actions you can perform with the application's user interface aren't exposed as objects in VBA. For example, there are no objects for digitally signing a VBA project. On the other hand, many objects provide more specific control than is available through the user interface. For example, by using the Assistant object you can programmatically perform specific animations of the Office Assistant that aren't exposed directly through the user interface. Also, some objects provide control over lower-level functions of the application that have no user interface. For example, the Err object allows you to trap errors so that you can anticipate situations that would otherwise cause your program to stop working, or leave users confused about the correct action to take.
The objects exposed by an application are arranged relative to each other in hierarchical relationships*.* The top-level object in an Office application is the Application object, which represents the application itself. The Application object contains other objects that you have access to only when the Application object exists (that is, when an instance of the application itself is running). For example, the Excel Application object contains Workbook objects, and the Word Application object contains Document objects. Because the Document object depends on the existence of the Word Application object for its own existence, the Document object is said to be the child of the Application object; conversely, the Application object is said to be the parent of the Document object.
Many child objects have children of their own. For example, the Excel Workbook object contains, or is parent to, the Worksheets object. The Worksheets object is a special kind of object called a collection that represents a set of objects - in this case, all the worksheets in the workbook, which in turn are represented as individual Worksheet objects within that collection. A parent object can have multiple children; for instance, the Word Window object has as children the Document, Panes, Selection, and View objects. Additionally, identically named child objects may belong to more than one parent object; for instance, in Word, both the Application object and the Document object have a Windows collection as a child object. However, even though the child objects have the same name, typically their functionality is determined by the parent object; for example, the Windows collection for the Application object contains all the current document windows in the application, whereas the Windows collection for the Document object contains only the windows that display the specified document.
Figure 4.1 The Windows Collection Portion of the Word Object Model
.gif)
To view graphical representations of the object models for Office applications and shared components, see , or see the topics "Microsoft Office Objects," "Microsoft Access Objects," "Microsoft Excel Objects," "Microsoft FrontPage Objects," "Microsoft Outlook Objects," "Microsoft Word Objects," or "Microsoft PowerPoint Objects," in the Visual Basic Reference Help for that application.
In addition to containing child objects, each object in the hierarchy contains content and functionality that apply both to the object itself and to all its child objects. The higher an object is in a hierarchy of nested objects (that is, the more child objects an object has), the wider the scope of its content and functionality. For example, in Excel, the Application object contains the size of the application window and the ability to quit the application; the Workbook object contains the file name and format of the workbook and the ability to save the workbook; the Worksheets collection contains Worksheet object names and the ability to add and delete worksheets.
You often don't get to the actual contents of a file, such as the values on an Excel worksheet or the text in a Word document, until you've navigated through several levels in the object hierarchy. This is because the scope of this specific content belongs to a particular functionality of the application. For example, the value in a cell on a worksheet applies only to that cell, not to all cells on the worksheet, so you can't store the value directly in a Worksheet object.
To work with the content and functionality exposed by an object, you use properties and methods of that object. You use properties to determine or change some characteristic of an object, such as its color, dimensions, or state. For example, you can set the Visible property of an Excel Worksheet object to specify whether a worksheet is visible to the user. You use methods to perform a particular action on an object. For example, you use the PrintOut method of the Word Document object to print the document. For more information about using properties and methods, see "Using Properties and Methods" later in this chapter.
Some objects also respond to events. An event is an action that is typically performed by a user such as clicking a mouse, pressing a key, changing data, or opening a document or form, but can also be performed by program code, or by the system itself. You can write code, called an event procedure, that will run whenever an event occurs. For example, you can write code in a form's Open event to size or position the form whenever it is opened. For more information about working with events, see "Working with Events" later in this chapter.
In summary, the representation of content and functionality in an application is divided among the objects in the application's object model. Together, the objects in the object model's hierarchy represent all the content and functionality in the application that is exposed to Visual Basic. Separately, the objects provide access to very specific areas of content and functionality. To determine or set a characteristic of an object, you read or set one of the object's properties. To perform an action on or with an object, you use one of the object's methods. Additionally, some objects provide events that are typically triggered by a user's action, so that you can write code that will run in response to that action.
Working with the Outlook Object Model
Outlook's programming model differs somewhat from the other Office applications. You can work with Outlook's object model in three ways:
You can write VBA code that runs from a local project file or a COM add-in that is associated with the local installation of Outlook.
You can use the native scripting environment available within the Outlook forms that are used to display items such as messages and appointments.
You can use Automation to work with Outlook from other Office applications and applications that support VBA.
To write VBA code that runs from a local project file (VBAProject.OTM), open Outlook, point to Macro on the Tools menu, and then click Visual Basic Editor. In Outlook, the Visual Basic Editor allows you to write code that can be run from this installation of Outlook only. For example, by adding code to the ThisOutlookSession module, you can write code against the following Application object events: ItemSend, NewMail, OptionsPagesAdd, Quit, Reminder, and Startup. Just as with other Office applications, you can insert code modules, class modules, and UserForms to further customize your solution, and you can run procedures from menu items or toolbar buttons.
To distribute a solution created by using a local Outlook VBA project, you can export your modules and objects to files and then import them on other machines where Outlook is installed. However, a much better way to distribute your solution is to compile and install your solution as a COM add-in by using the COM add-in designer available in Microsoft Office 2000 Developer or in Microsoft Visual Basic 6.0. For more information about creating COM add-ins, see Chapter 11, "Add-ins, Templates, Wizards, and Libraries." For more information about using VBA within Outlook, see "Working with Microsoft Outlook Objects" in Chapter 5, "Working with Office Applications."
To write script that runs within Outlook items, you use the Outlook Script Editor. Outlook forms (that is, all items you can open in Outlook, such as messages, appointments, and contacts) support scripting in Microsoft Visual Basic Scripting Edition (VBScript) by using the Outlook Script Editor. Because VBScript is a subset of VBA, there are limitations to what you can do; for example, VBScript supports only one data type, the Variant data type, and a number of VBA keywords and features aren't supported. For more information about scripting, see Chapter 12, "Using Web Technologies." To access the Outlook Script Editor, you must be in form design mode.
To open the Outlook Script Editor
Open the Outlook item you want to base your form on.
On the Tools menu, point to Forms, and then click Design This Form. To start from an existing custom form, point to Forms on the Tools menu, click Design a Form, and then select a form.
Make any changes you want to the design of the form.
On the Form menu, click View Code.
When working with scripting in Outlook forms, you will most typically be writing event procedures. For example, you may want to write an event procedure for your form's Open event to initialize the form to display a particular tab page and enter default values in certain fields. To add an event handler stub to the Outlook Script Editor, click Event Handler on the Script menu, select the event you want to work with, and then click Add. For more information about the Outlook object model, click Microsoft Outlook Object Library Help on the Help menu in the Outlook Script Editor.
To work with Outlook from another application, you can use Automation code with either early binding or late binding. To use early binding, establish a reference to the Microsoft Outlook 9.0 object library and then declare and initialize an object variable that references the Outlook Application object. For example:
Dim olApp As Outlook.Application
Set olApp = New Outlook.Application
Similarly, you can use the CreateObject function with an object variable declared as type Object to initialize a late-bound object variable. For example:
Dim olApp As Object
Set olApp = CreateObject("Outlook.Application")
Either way, you can then use this object variable to work with the other objects, properties, methods, and events of the Outlook object model.
For more information about using Automation code with Outlook, see "Creating an Object Variable to Automate Another Office Application" later in this chapter, and "Working with Microsoft Outlook Objects" in Chapter 5, "Working with Office Applications."