InformIT: Visual C++ 6 Unleashed > COM and OLE from the Eyes of the End User

Table of Contents

COM and OLE from the Eyes of the End User

Although many software engineers forget it, the end user is the main reason for our existence as software developers. Because the end user is the main reason software is developed, this section will view OLE from the user's eyes. This will help you grasp the benefits and the available services of COM, OLE, and Active Technologies. The end user's view is simple, less technical, and very understandable. I firmly believe that users decide in the first ten minutes of using an application whether they like it. This sets the stage for all further experiences using that application. Therefore, an application's intuitiveness, appearance, ease of use, capability of performing work or entertainment, and performance are of paramount importance.

Microsoft—and Apple before it—knew that a large portion of the software had to have a human-to-machine interface. This is why Windows and the Macintosh each have a standard interface—not only from a user's perspective, but also from a programmer's perspective.

Users interact with COM, OLE, and Active Technologies in three ways:

Documents, including OLE Documents and the newer Active Documents
Automation, formerly known as OLE Automation
ActiveX controls and COM objects

Many of the COM, OLE, and Active Technologies are hidden from the end user. For example, a typical end user has no idea that an ActiveX control is being used. Nor is he likely to know that a particular document is an Active Document launched from a compound file instead of a normal text file. However, the end user is likely to be aware of the ease of use that occurs when using a specific application or opening a specific document.

As a computer professional, I am sure you have seen or worked with Microsoft Word or Excel. Microsoft Word is the classic example of an application that creates OLE documents. In other words, Word is an OLE document server. This chapter is not going to outline the functionality of Word, but merely point out the features of COM and OLE that are used by it and similar applications. However, do not be deceived; OLE document servers are not always classic word processors. Think of OLE containers and servers as pieces of Velcro. You have two pieces: the hook side (the document server) and the pile side (the document container).

The first feature of OLE documents is a common user model. This simply means that the user interface (UI) features used to access OLE documents are similar from application to application. The common user model features document-centricity and takes advan tage of OLE's integrated data capabilities.

One of these integrated data capabilities is called linking and embedding. Data objects of different types, created from other applications, can be embedded or linked into an application's OLE document. This enables the user to manipulate the object in the host application without returning to the creating application. The object is simply edited in place, hence the term in-place editing. The user interface is modified in the host application with menus, toolbars, and context menus from the application that created the object.

In Figure 24.2, take note of the two kinds of data—text and an embedded Visio drawing. Note also the toolbars and menu.

Figure 24.2 A Microsoft Word document with embedded text and graphics.

If you double-click the Visio Drawing, the Word application changes, and new user interface objects are added to Word from Visio (see Figure 24.3). Notice that the Word user interface performs a metamorphosis and now has the Visio toolbars, floating dialog boxes, and menu items, as well as the Visio drawing and rulers. The user can then edit this drawing object without switching applications. In addition, these objects can be dragged and dropped between and within applications.

Figure 24.3 A Microsoft Word document with the Visio drawing activated for in-place editing.

These features are implemented in the same way from application to application. Thus, there is a smaller learning curve for users when they get new applications, because the applications function similarly and have a common user model.

The next level of visibility to the user is Automation. Automation enables the user to access and modify objects through properties and methods, using a high-level language such as Visual Basic for Applications (VBA), VBScript, or JavaScript. This enables the user to customize objects and the interactivity between objects to perform operations the way the user defines. Microsoft Excel spreadsheets are the classic Automation objects. The user can create Excel spreadsheets that update a Microsoft Graph object or update information in a Microsoft Access database.

This leads us to ActiveX controls. ActiveX controls are the last area of COM, OLE, and Active Technology visibility to the end user. They are self-contained, reusable components that can be embedded in applications. To the users, they are nothing more than a control that takes their input and passes it to the application that contains it. However, some ActiveX controls are static in nature, such as a picture control. ActiveX controls are also Automation Servers that can have properties set at both compile time and runtime, and ActiveX controls typically have methods that can perform certain operations. The difference between an ActiveX control and Automation Server is that an ActiveX control is a self-contained component.

ActiveX controls also take advantage of two-way communication between the control and the container. This enables an ActiveX control to have an even more special ability beyond simple Automation: It can initiate events that are sent to the control's container.

ActiveX controls also expose properties and methods that may be manipulated. An ex ample of a property might be the date value or the background color in the Microsoft MonthView control shown in Figure 24.4. A method might be a function that changes the date value or the background color. To clarify an event, the MonthView control might have an event fired, when the user clicks a day, that lets the container know that a day has been clicked. These properties, methods, and events make ActiveX controls powerful. They give the programmer and the end user a wide range of functionality, as shown in Figure 24.4.

Figure 24.4 Properties, methods, and events of the Microsoft MonthView control during development in the Visual C++ Developer Studio.

In future sections, you will discover that ActiveX controls have had a very profound impact in the area of application development (see Figure 24.5), because they are ready-made, self-contained components. From the end user's perspective, they provide increased functionality and lower software costs.

Figure 24.5 Two ActiveX controls embedded in an application. The Microsoft Date and Time Picker control is located above the Microsoft MonthView control. These controls come with Visual C++.

COM, OLE, and Active Technologies from a Programmer's View | Next Section

Previous Section