| C & C++ Programming | MFC Programming | Download | Site Index |


 

 

 

 

 

Supplementary Notes For MFC Programming Module 23 and Module 27:

Interfaces, COM, COM+ and OLE

 

 

 

 

 

What do we have in this Module?

  1. What Support for an Interface Means

  2. OLE Background

  3. The Component Object Model

  4. COM+ Programming Overview

  5. Application and Component Administration

  6. Automatic Transactions

What Support for an Interface Means

 

Besides the IUnknown interface, an ActiveX Control, or COM Object for that matter, expresses whatever optional functionality it supports through additional interfaces. This is to say that no other interfaces are required above IUnknown. To that end, the following table lists the interfaces that an ActiveX Control might support, and what it means to support that interface. Further details about the methods of these interfaces are given in a later section.

 

Interface

Comments/What it Means to Support the Interface

IOleObject

If the control requires communication with its client site for anything other than events (see IConnectionPointContainer), then IOleObject is a necessity. When implementing this interface, the control must also support the semantics of the following methods: SetHostNames(), Close(), EnumVerbs(), Update(), IsUpToDate(), GetUserClassID(), GetUserType(), GetMiscStatus(), and the Advise(), Unadvise(), and EnumAdvise() methods that work in conjunction with a container’s IAdviseSink implementation. A control implementing IOleObject must be able to handle IAdviseSink if the container provides one; a container may not, in which case a control ensures, of course, that it does not attempt to call a non-existent sink.

IOleInPlaceObject

Expresses the control’s ability to be in-place activated and possibly UI activated. This interface means that the control has a user interface of some kind that can be activated, and IOleInPlaceActiveObject is supported as well. Required methods are GetWindow(), InPlaceActivate(), UIDeactivate(), SetObjectRects(), and ReactivateAndUndo(). Support for this interface requires support for IOleObject.

IOleInPlaceActiveObject

An in-place capable object that supports IOleInPlaceObject must also provide this interface as well, though the control itself doesn’t necessarily implement the interface directly.

IOleControl

Expresses the control’s ability and desire to deal with:

 

(a) Mnemonics (GetControlInfo(), OnMnemonic() methods),

(b) Ambient properties (OnAmbientPropertyChange()), and/or

(c) Events that the control requires the container to handle (FreezeEvents()).

 

Note that mnemonics are different than accelerators that are handled through IOleInPlaceActiveObject: mnemonics have associated UI and are active even when the control is not UI active. A control’s support for mnemonics means that the control also knows how to use the container’s IOleControlSite::OnControlInfoChanged method. Because this requires the control to know the container’s site, support for mnemonics also means support for IOleObject. In addition, knowledge of mnemonics requires in-place support and thus IOleInPlaceObject.

If a control uses any container-ambient properties, then it must also implement this interface to receive change notifications, as following the semantics of changes is required. Because ambient properties are only available through the container site’s IDispatch, ambient property support means that the control supports IOleObject (to get the site) as well as being able to generate IDispatch::Invoke calls.

The FreezeEvents() method is necessary for controls that must know when a container is not going to handle an event; this is the only way for control to know this condition. If FreezeEvents() is only necessary in isolation, such that other IOleControl methods are not implemented, then IOleControl can stand alone without IOleObject or IOleInPlaceObject.

IDataObject

Indicates that the control can supply at least:

 

(a) Graphical renderings of the control (CF_METAFILEPICT is the minimum if the control has any visuals at all) and/or

(b) Property sets, if the control has any properties to provide.

 

The methods GetData(), QueryGetData(), EnumFormatEtc(), DAdvise(), DUnadvise(), and EnumDAdvise() are required. Support for graphical formats other than CF_METAFILEPICT is optional.

IViewObject2

Indicates that the control has some interesting visuals when it is not in-place active. If implemented, a control must support the methods Draw(), GetAdvise(), SetAdvise(), and GetExtent().

IDispatch

Indicates that the control has either:

 

(a) Custom methods, or

(b) Custom properties that are both available via late-binding through IDispatch::Invoke.

 

This also requires that the control provides type information through other IDispatch methods. A control may support multiple IDispatch implementations where only one is associated with IID_IDispatch, the others must have their own unique dispinterface identifiers. A control is encouraged to supply dual interfaces for custom method and property access, but this is optional if methods and properties exist.

IConnectionPointContainer

Indicates that a control supports at least one outgoing interface, such as events or property change notifications. All methods of this interface must be implemented if this interface is available at all, including EnumConnectionPoints() which requires a separate object with IEnumConnectionPoints().

Support for IConnectionPointContainer means that the object also supports one or more related objects with IConnectionPoint that are available through IConnectionPointContainer methods. Each connection point object itself must implement the full IConnectionPoint interface, including EnumConnections(), which requires another enumerator object with the IEnumConnections() interface.

 

 

 

 

 

 

 

 

 

 

 

 

 

IProvideClassInfo[2]

Indicates that the object can provide its own coclass type information directly through IProvideClassInfo::GetClassInfo. If the control supports the later variation IProvideClassInfo2(), then it also indicates its ability to provide its primary source IID through IProvideClassInfo2::GetGUID. All methods of this interface must be implemented.

ISpecifyPropertyPages

Indicates that the control has property pages that it can display such that a container can coordinate this control’s property pages with other control’s pages when property pages are to be shown for a multi-control selection. All methods of this interface must be implemented when support exists.

IPerPropertyBrowsing

Indicates the control’s ability to:

 

(a) Provide a display string for a property,

(b) Provide pre-defined strings and values for its properties and/or

(c) Map a property dispID to a specific property page.

 

Support for this interface means that support for properties through IDispatch as above is provided. If (c) is supported, then it also means that the object’s property pages mapped through IPerPropertyBrowsing::MapPropertyToPage themselves implement IPropertyPage2 as opposed to the basic IPropertyPage interface.

IPersistStream

See Persistence Interfaces section.

IPersistStreamInit

See Persistence Interfaces section.

IPersistMemory

See Persistence Interfaces section.

IPersistStorage

See Persistence Interfaces section.

IPersistMoniker

See Persistence Interfaces section.

IPersistPropertyBag

See Persistence Interfaces section.

IOleCache[2]

Indicates support for container caching of control visuals. A control generally obtains caching support itself through the OLE function CreateDataCache(). Only controls with meaningful static content should choose to do this (although it is not required). If a control supports caching at all, it should simply aggregate the data cache and expose both IOleCache and IOleCache2 interfaces from the data cache. A control implementing IOleObject must be able to handle IAdviseSink if the container provides one; a container may not, in which case a control ensures, of course, that it does not attempt to call a non-existent sink.

IExternalConnection

Indicates that the control supports external links to itself; that is, the control is not marked with OLEMISC_CANTLINKINSIDE and supports IOleObject::SetMoniker and IOleObject::GetMoniker. A container will never query for this interface itself nor call it directly as calls are generated from inside OLE’s remoting layer.

IRunnableObject

Indicates that the control differentiates being loaded from being running, as some in-process objects do.

 

 Table 1.

 

OLE Background

 

OLE is a mechanism that allows users to create and edit documents containing items or "objects" created by multiple applications. OLE was originally an acronym for Object Linking and Embedding. However, it is now referred to as OLE. Parts of OLE not related to linking and embedding are now part of Active technology. OLE documents, historically called compound documents, seamlessly integrate various types of data, or components. Sound clips, spreadsheets, and bitmaps are typical examples of components found in OLE documents. Supporting OLE in your application allows your users to use OLE documents without worrying about switching between the different applications; OLE does the switching for you. You use a container application to create compound documents and a server application or component application to create the items within the container document. Any application you write can be a container, a server, or both. OLE incorporates many different concepts that all work toward the goal of seamless interaction between applications. These areas include the following:

 

Application

Description

Linking and Embedding

Linking and embedding are the two methods for storing items created inside an OLE document that were created in another application.

In-Place Activation (Visual Editing)

Activating an embedded item in the context of the container document is called in-place activation or visual editing. The container application's interface changes to incorporate the features of the component application that created the embedded item. Linked items are never activated in place because the actual data for the item is contained in a separate file, out of the context of the application containing the link. Note:   Linking and embedding and in-place activation provide the main features of OLE visual editing.

Automation

Automation allows one application to drive another application. The driving application is known as an automation client, and the application being driven is known as an automation server or automation component.

Note:   Automation works in both OLE and Active technology contexts. You can automate any object based on COM.

Compound Files

Compound files provide a standard file format that simplifies structured storing of compound documents for OLE applications. Within a compound file, storages have many features of directories and streams have many features of files. This technology is also called structured storage.

Uniform Data Transfer

Uniform Data Transfer (UDT) is a set of interfaces that allow data to be sent and received in a standard fashion, regardless of the actual method chosen to transfer the data. UDT forms the basis for data transfers by drag and drop. UDT now serves as the basis for existing Windows data transfer, such as the Clipboard and dynamic data exchange (DDE).

Drag and Drop

Drag and drop is an easy-to-use, direct-manipulation technique to transfer data among applications, among windows within an application, or even within a single window in an application. The data to be transferred is selected and dragged to the desired destination. Drag and drop is based on uniform data transfer.

Component Object Model

The Component Object Model (COM) provides the infrastructure used when OLE objects communicate with each other. The MFC OLE classes simplify COM for the programmer. COM is part of Active technology, because COM objects underlie both OLE and Active technology.

 

 Table 2.

 

MFC provides the easiest way to write programs that use OLE:

  1. To use OLE visual editing (in-place activation).

  2. To work as OLE containers or servers.

  3. To implement drag-and-drop functionality.

  4. To work with date and time data.

  5. To manage the state data of MFC modules, including exported DLL function entry points, OLE/COM interface entry points, and window procedure entry points.

You can also use Automation or Remote Automation to operate another program from your program. Note:   The term OLE denotes the technologies associated with linking and embedding, including OLE containers, OLE servers, OLE items, in-place activation (or visual editing), trackers, drag and drop, and menu merging. The term Active applies to the Component Object Model (COM) and COM-based objects such as ActiveX controls. OLE Automation is now called Automation. A subset of MFC is designed to support COM, while most of the Active Template Library (ATL) is designed for COM programming. Active technologies (such as ActiveX controls, Active document containment, OLE, and so on) use the Component Object Model (COM) to enable software components to interact with one another in a networked environment, regardless of the language with which they were created. Active technologies can be used to create applications that run on the desktop or the Internet. Active technologies include both client and server technologies, including the following:

  1. Active document containment supported in MFC versions 4.2 and later, allows users to view active documents (such as Microsoft Excel or Word files) and activate the entire interface of the document's native application in the entire client area of an active document container such as the Microsoft Office Binder or Microsoft Internet Explorer. The containers act as clients, while the documents are provided by active document servers.

  2. ActiveX controls are interactive objects that can be used in containers such as a Web site.

  3. Active scripting controls the integrated behavior of one or more ActiveX controls from a browser or server.

  4. Automation (formerly known as OLE Automation) makes it possible for one application to manipulate objects implemented in another application, or to "expose" objects so they can be manipulated. The automated object might be local or remote (on another machine accessible across a network). Automation is available for both OLE and COM objects.

The Component Object Model

 

The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX® (Internet-enabled components), as well as others. To understand COM (and therefore all COM-based technologies), it is crucial to understand that it is not an object-oriented language but a standard. Nor does COM specify how an application should be structured; language, structure, and implementation details are left to the application programmer. Rather, COM specifies an object model and programming requirements that enable COM objects (also called COM components, or sometimes simply objects) to interact with other objects. These objects can be within a single process, in other processes, and can even be on remote machines. They can have been written in other languages, and they may be structurally quite dissimilar, which is why COM is referred to as a binary standard, a standard that applies after a program has been translated to binary machine code.

The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers. Object-oriented languages such as Microsoft® Visual C++® and Smalltalk provide programming mechanisms that simplify the implementation of COM objects, but languages such as C, Pascal, Ada, Java, and even BASIC programming environments can create and use COM objects.

COM defines the essential nature of a COM object. In general, a software object is made up of a set of data and the functions that manipulate the data. A COM object is one in which access to an object's data is achieved exclusively through one or more sets of related functions. These function sets are called interfaces, and the functions of an interface are called methods. Further, COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface. Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of API functions that all components require. COM also defines how objects work together over a distributed environment and has added security features to help provide system and component integrity.

 

COM+ Programming Overview

 

COM+ provides an enterprise development environment, based on the Microsoft Component Object Model (COM), for creating component-based, distributed applications. It also provides you with the tools to create transactional, multitier applications. COM+ combines enhancements to traditional COM-based development with many useful programming and administrative services. The COM enhancements include improvements in both threading and security, along with the introduction of synchronization services. The services include the Component Services administrative tool, which you can find in the Administrative Tools section of Microsoft® Windows® 2000 and later releases of Microsoft Windows operating systems.

For those familiar with COM programming, the COM+ improvements are significant, including the following:

  1. COM+ implements a threading model called neutral apartment threading, which allows a component to have serialized access along with the ability to execute on any thread.

  2. COM+ supports components with a special environment called a context, which provides an extensible set of properties that define the execution environment for the component.

  3. COM+ provides role-based security, asynchronous object execution, and a built-in moniker that represents a reference to an object instance running on an out-of-process server.

Application and Component Administration

 

In COM+, a registration database, named RegDB, stores the metadata that describes components. This database is highly optimized for the type of information that COM+ needs for activation of components and is used instead of the system registry. In addition, COM+ exposes the COM+ catalog, which accesses information in the RegDB. The COM+ catalog is a system data store that contains configuration information for COM+ applications on a given server computer. Finally, the Component Services administrative tool provides a fully scriptable user interface for developers and administrators to administer components as well as deploy both client-side and server-side multitier applications.

 

Automatic Transactions

 

COM+ supports all Microsoft Transaction Server (MTS) 2.0 semantics and adds the auto-done capability, which you can set by using the Component Services administrative tool and which allows the system to abort a transaction automatically if an exception is triggered or to commit if not.

 

 

 

 

 


| C & C++ Programming | MFC Programming | Download | Site Index |