Understanding OLE

By Ken North
DBMS, June 1995

Microsoft's language-independent, binary standard for object sharing on desk-tops and across networks.

The maturation of the computing industry has some parallels with agri-business, where, in developed nations, a few producers supply the needs of many consumers. One widely accepted view of our computing future is that we will eventually become a community with a few producers (object implementors) supplying many consumers (object users). The consumers will be programmers and power users who will build applications by drawing from a stock of interoperable objects before writing custom code or building custom objects to fill in functionality gaps. The Microsoft contribution to this view of computing with shared objects, or component objects, is Object Linking and Embedding (OLE). [For a complete list of the acronyms used in this article, please see Table 1.]

OLE provides a language-independent, binary standard for object sharing. Before jumping into this technology, you should understand OLE, the Component Object Model (COM), services that build on COM, and OLE custom controls (OCXs). COM is a core technology for creating shareable binary components. It provides the infrastructure upon which OLE layers other software services. COM is a language-independent binary standard that permits object sharing by applications written in a variety of languages. OCXs are Windows controls that provide data-binding capabilities that make them particularly suited to database work. In addition to these technologies, Microsoft has launched an initiative that creates a data integration layer over COM. (See the sidebar, "Nile, Microsoft's Data Integration Initiative".) In this article, I look at each of these topics in more detail.

Microsoft is working on an update to the current OLE 2.0 that will provide interoperable and distributed objects. The company released a revised specification for OLE's COM in March 1995. This specification update discusses distributed objects based on Open Software Foundation's Distributed Computing Environment (DCE) Remote Procedure Calls (RPCs). The COM network protocol is based on the 1994 X/Open DCE RPC Common Applications Environment (CAE) specification. Distributed OLE adds new interfaces related to remote objects, but it is basically an upward extension that shouldn't break existing OLE code.

Microsoft considers OLE a precursor to Cairo, its next-generation operating system that will expose operating system services as objects. Other interoperable object solutions that have become prominent recently include the Object Management Group's Common Object Request Broker Architecture (CORBA), Component Integration Lab's OpenDoc, IBM's System Object Model (SOM), and SunSoft's Distributed Objects Everywhere (DOE). OLE 2.0 has a significant following within the developer community, even though proponents of other technologies such as OpenDoc and CORBA argue that these solutions are technically superior to OLE. CORBA enjoys support in Unix environments, while OLE has become a de facto object standard for Windows computing.

The Rationale for Object Sharing

Some automobile drivers prefer the direct control of a four- or five-speed transmission while others prefer the ease of an automatic transmission. Some programmers work with call-level interfaces (CLIs) such as OSF/DCE or the Windows API; other developers look for object solutions to simplify programming. This latter demographic is the focus for software giants such as IBM and Microsoft, who recognize that capturing the support of this developer group is critical to capturing market share in the 21st century. Object-sharing technology is integral to the architecture of operating systems currently in development.

A developer's choice of programming techniques often involves the level of abstraction at which to operate. Object techniques raise the level of abstraction by encapsulating low-level programming details. For example, a programmer working at a lower level will dig into DCE's 400-plus system calls to use RPCs. A programmer working at a higher level uses a technology such as OLE, which builds on DCE. OLE encapsulates functionality that lets a developer deal with an object without concern for whether the object is local or remote. OLE objects are defined in a registry, so they are usable across applications and available to scripting languages such as Visual Basic for Applications. Microsoft predicts that programming with OLE interfaces will eventually supplant most detail-level programming in Windows and Cairo applications (much as assembly language gave way to higher-level languages).

To understand OLE you should know a few terms and concepts (and a slew of acronyms, as you may have noticed from Table 1). A container is an entity that contains linked or embedded objects. Users of OLE container applications create and manage compound documents that consist of objects from multiple source applications. Objects linked to or embedded within other objects are nested. An application that creates and manages compound documents is a container application. Server applications are object implementors because they create and maintain Windows objects. OLE uses several types of identifiers to define interfaces and object classes uniquely. The universal identifier is the globally unique identifier (GUID), a 128-bit value that provides a unique identity for each interface and object class. OLE also uses a class identifier (CLSID) for every standard object class, and an interface identifier (IID) for every standard interface. Windows Objects are component objects with a unique CLSID. The registration database, or registry, contains the inventory of available objects. It includes a unique CLSID entry for each component object class.

COM and Service Layers

If you understand the rationale for objects, you are probably wondering what services OLE provides to application developers. The short answer is that OLE provides services for object sharing and component integration. The heart of OLE is COM, which is the foundation upon which Microsoft built additional services. Figure 1 shows the various OLE services, which build on COM. COM provides memory management, error handling, interface negotiation, interprocess communication, and other basic services for component object management. To use OLE, you must install a variety of Windows dynamic link libraries (DLLs), including compobj.dll, the DLL that supports COM.

When you instantiate a component object, you receive a pointer to the object's interface. OLE objects implement one or more interfaces that provide access to an object's member functions but not its data. Figure 2 illustrates multiple interfaces for a single object. The instantiation of an interface is an array of pointers to member functions (the implementation of the interface). An interface is analogous to a C++ abstract base class or a collection of methods. Applications use OLE services by accessing the interfaces defined in Table 2. By calling the interface, a program can obtain a pointer to a table that contains an entry for each function available through that interface. The table is a virtual table (vtable or VTBL) whose entries are themselves pointers to functions.

OLE supports dynamic binding, so you can determine at runtime what functions an interface provides. To support this type of programming, every object implements an interface called IUnknown, which provides a standard member function called QueryInterface. Instead of resolving addresses and type information at link time, an application can obtain this information from QueryInterface at runtime.

All OLE interfaces are derivatives of IUnknown; therefore, every object interface supports QueryInterface. The notation for an OLE call is similar to C++, where you specify a classname::member function. For OLE, you use an interface::member function so that an application that wants to save text to a file would call IPersistFile::Save, where IPersistFile is the interface and Save is the member function (or method).

COM uses a client/server model in which object users are clients and object implementors are servers. In-Process servers execute within the client's address space, while Out-of-Process servers are standalone executables. Clients and servers use a class factory, a feature within the server module that creates objects. Client access to the class factory occurs via the server's IClassFactory interface. COM client applications use the same process to instantiate an object whether the server is In-Process, local, or remote. The client passes a CLSID to COM when instantiating an object. To ask the class factory to manufacture one or more objects, the client obtains the pointer to IClassFactory and calls CoGetClassObject. The client can also call COM's CoCreateInstance to create a single instance (one object).

Marshalling, the process of passing function calls and parameters across process boundaries, handles differences related to different word sizes. It enables objects having 16-bit parameters to interoperate with those having 32-bit parameters. COMPOBJ.DLL contains the marshalling code that resolves addressing differences, so that object users see an object that matches their own address space and has the correct byte ordering.

Marshalling is handled by components called proxy objects. Unmarshalling is handled by stub component objects. Every interface has its own proxy object to package method parameters for that interface. OLE uses Lightweight Remote Procedure Calls (LRPCs) for marshalling local objects, and DCE-compliant ORPCs ("object" RPCs) for distributed objects. OLE uses an object description language (ODL) and type libraries (TLBs) to describe objects. The text descriptions in ODL are compiled to produce the TLB, which is an OLE compound document file that contains descriptions of types, modules, and interfaces.

OLE provides more than basic component object management. The additional services that build upon COM include Structured Storage, Monikers, Uniform Data Transfer, Drag and Drop, Linking, Embedding, In-Place Activation, and Automation. The OCX architecture adds Controls, Property Page, Property Change Notification, Events, and Connectable Objects. OLE implements a standard set of protocols for performing a variety of data-transfer operations, including drag-and-drop, clipboard control, and compound document processing. Uniform Data Transfer simplifies data transfers and change notification (for example, clipboard cut-and-paste operations). In-Place Activation lets users edit, display, record, and play data without switching to a different window. A Moniker is a Windows Object that describes the data source and includes code for data binding. OLE includes five Moniker classes: Composite, File, Item, Anti, and Pointer. Linking places only rendering information and a pointer to an object's data in a compound document. Embedding places the rendering information and the object data within the document. It is possible to edit an embedded object in-place or within its own container, because the compound document includes a copy of the original embedded object and all of the information needed to manage the object.

Automation and Structured and Persistent Storage

OLE Automation lets applications create and expose command sets for interapplication operations. Applications can operate each other without human intervention, and developers can write commands and macros that operate across application boundaries. Automation lets object users manipulate objects by setting properties or calling methods with optional arguments. An interface called IDispatch allows runtime binding to object methods and properties.

OLE supports a model for structured storage that uses compound files instead of traditional file-system interfaces, which use handles. OLE's storage.dll provides services for compound files, making it the forerunner of the future Windows file system. OLE Structured Storage includes two object types: streams and storages. Storage objects are similar to directories containing other storage and stream objects. Streams contain unformatted or unstructured data. Storage objects and stream objects support direct data access and a transaction mode for committing changes to data. Objects that are stored using a persistent medium, such as a magnetic disk, are persistent objects. OLE provides several interfaces for persistent objects (such as IPersistFile, IPersistStorage, and IPersistStream). Component objects can save their persistent state by implementing IPersistStream and IPersistStorage.

Plug-In Components

The third-party market for plug-in components may speed OLE's adoption by Windows programmers. The 16- and 32-bit OCXs are likely to succeed the 16-bit Visual Basic Extension (VBX), the most widely used component software today. OCXs are actually In-Process servers that support in-place activation and OLE automation. OCXs brought new capabilities to OLE, including outgoing interfaces and an event model (which associates events with the code that handles those events) to support event-driven programming. Containers use "outgoing interfaces" to activate their OLE custom controls in response to events.

Distributed OLE

With distributed OLE, Microsoft intends to support partitioning in order to enable applications to use local or remote components. COM provides location transparency, so an object's programming interface won't change, whether it is local or remote. OLE does the work behind the scenes, and uses ORPCs for remote objects and LRPCs for local objects. To make remote operations transparent, COM disables features that would be appropriate for In-Process objects but are inappropriate for Out-of-Process objects.

Microsoft built distributed OLE on a DCE foundation. It uses the DCE security model, naming conventions, and directory services. Also, the OLE Interface Definition Language (IDL) is an extended version of the DCE IDL. Distributed OLE uses DCE RPCs and supports the use of custom RPCs, as long as they are DCE-compliant. It also handles marshalling for objects based on a variety of CPUs. Jeff Alger, one of Microsoft's OLE gurus, describes the next version of OLE as being a "DCE implementation with value-added for COM. It supplements DCE; it doesn't reinvent it."

COM uses proxies and stubs to support object location transparency. Whether an object server is local or remote, it creates a proxy object to act as an In-Process object in the client. The proxy object then talks to stubs that run in the server. A COM component, the Service Control Manager (SCM), manages the connections to remote servers, so that the server is readily accessible when a client issues a request. SCM keeps a database of class information based on registry information. The SCM will return file path information, start an executable, and return a pointer or forward the request to--and maintain--an RPC connection with the remote SCM.

OLE also lets you override location transparency with custom marshalling. This capability provides additional control when the separation of interface and implementation introduces too much of a performance penalty across a network.

Error Handling and Debugging

Because OLE's error-handling is language-independent, it is illegal to throw an exception across an interface. (An application signals an error condition by throwing an exception. An error handler uses catch to state that it handles certain types of exceptions.) Instead, COM interface functions use return codes to indicate errors. COM defines an HRESULT type, functions, and macros to handle and report errors. HRESULT is a long integer that consists of 13 bits for facility information and 16 bits for an error code. The facility code identifies a grouping such as dispatch errors, RPC errors, Win32 errors, persistent-storage errors, and so on.

The COM Network Protocol and the COM Library support debugging libraries at either client or server, or on both sides of a COM invocation. The debuggers can use hooks at either end of the RPC infrastructure to invoke debugger actions. Also, COM RPC debugging can use Windows NT and Windows 95 facilities to spawn a debugger when an application faults.

DBMS Interfaces Using OLE

The typical programming interface for database applications today is a CLI in which the functions that provide database services reside in a separate library. To provide OLE-based database access, some companies create an object layer that encapsulates a DBMS CLI. Oracle Corp.'s Oracle Objects for OLE encapsulates the Oracle Call Interface (OCI), and Sylvain Faust Inc.'s SQL Sombrero encapsulates SQL Server's DB-Library and Sybase Open Client's CT-Library.

Microsoft Access and Visual Basic feature Data Access Objects (DAO), a collection of objects (such as Databases, Recordsets, and QueryDefs) that work with a variety of databases. The application uses a common programming model to operate against data that may be local or remote, desktop or server, ISAM or SQL. Today, DAO is an application-level object layer, but Microsoft's Nile will extend the scope to make objects available across applications and computers. My article "Multidatabase Development" (DBMS, October, page 76) provides more information about DAO.

Database developers are often justifiably concerned about committing resources to technologies that fall out of favor. SQL, ODBC, and the new ANSI/ISO CLI represent standards, but because object interfaces and visual controls are new technologies, some developers worry that they'll have to throw away code. Oracle Objects for OLE is one example of how code can be preserved while migrating to the new technology. Oracle Objects consists of visual controls and an object interface for Visual Basic that replaces the standard VB data control, but does not require major application recoding.

Implications for Client/Server

Today's client/server systems use stored procedures and triggers to implement rules. SQL3 (the next version of the ANSI SQL standard) uses the term "persistent stored modules" to describe procedures. OLE adds the flexibility to use objects at the client, and distributed OLE lets you use objects at the server or on other machines. Distributed objects provide more opportunities for logic distribution than the architectures that we describe now as "two-tier" and "three-tier" client/server systems. For example, repositories and rule-based servers could become factories for rules agents that operate at all levels of a distributed computing environment.

OLE has the potential to enable tools such as VB and Powersoft Corp.'s PowerBuilder to use shared objects to implement rules and provide access to repository information. Today, PowerBuilder provides extended attributes and event scripts to validate input, and VB provides methods for data validation, but client/server developers using those products often rely on server stored procedures to centralize more elaborate rules. OLE lets developers encapsulate rules in objects that are accessible to PowerBuilder, VB, or other OLE-enabled applications. For example, you could define the rules related to an organization's group health plan as OLE objects that are accessible to programmers and applications such as Excel. Repositories and distributed OLE will enable servers and client applications to use the same objects. This will help the development of enterprise-wide applications that use common rules.

Industry Support for OLE

At the February Software Development '95 Conference in San Francisco, Microsoft presented a chart that showed OLE on a growth curve that closely parallels Windows. According to Microsoft's research, there are currently 400 to 500 OLE applications from more than 300 independent software vendors. Database companies such as Oracle, Powersoft, and Gupta Corp. have developed new products or have added OCXs to existing products. Microsoft supports OLE for Windows and the Macintosh, while Bristol Technology Inc. offers OLE for Unix platforms. Bristol's Wind/U is a toolset that lets developers use Microsoft Foundation Classes and the Windows API while developing for Unix. Scott Wingo, one of the principal engineers of Wind/U, says Bristol plans to support Microsoft Foundation Classes 3.0 and OLE 2.0 with Wind/U by the summer of 1995.

There is other evidence of strong OLE support in the marketplace. A consortium of computer-aided design vendors and geographic information system software vendors recently adopted an OLE extension, OLE for Design and Modeling Applications, that supports embedding of technical graphics in 2D and 3D documents. Borland's C++ supports OLE 2.0 development with an engine (BOCOLE) that encapsulates OLE, and provides a complementary class library called the Object Components Framework. Microsoft's Visual C++ and the Microsoft Foundation Classes are popular for developing OLE-enabled applications. Visual C++ also includes an OLE Control Development Kit for developers who want to create OCXs. Visual Basic 3.0 can operate only as an OLE Automation client; however, Visual Basic 4.0 (scheduled for release when Windows 95 ships) will act as an Automation server and an OCX container.

The Great Object Debate

Comparisons of OLE with other object technologies often evolve into debates about subclassing, implementation inheritance, and compound documents. Subclassing is the process of deriving an object from a parent and modifying its behavior. OLE supports interface inheritance, but not implementation inheritance. One OLE object uses another object, rather than inheriting the object's implementation. Critics assert that OLE should support subclassing or inheritance of an object's implementation. Microsoft rebuts that argument by citing the lack of literature about guaranteed behavior and safe inheritance when implementing a binary object standard.

Comparisons of OLE and OpenDoc usually focus on the compound document architecture. OLE proponents raise questions about OpenDoc's ability to operate across multiple process spaces or the need to distribute parts viewers for compound documents. Despite the debate, developers who support other interoperable object technologies recognize OLE's growing popularity. Novell uses OLE as part of the infrastructure for the Windows version of OpenDoc. OMG members have also been reviewing proposals for CORBA and OLE interoperability. Regardless of the technical merits of each technology, it appears that OLE is here to stay.

Ken North is a consultant, author, and software developer. This article includes excerpts from his book Windows Multi-DBMS Programming, (John Wiley & Sons, 1995). You can contact Ken via CompuServe at 71301,1306 or at Resource Group Inc., 2604B El Camino Real, Ste. 351, Carlsbad, CA 92008-1234.

* Borland International, 100 Borland Way, Scotts Valley, CA 95066; 800-233-2444 or 408-461-9000.
* Bristol Technology Inc., 241C Ethan Allen Highway, Ridgefield, CT 06877; 203-438-6969 or fax 203-438-5013.
* Gupta Corp., 1060 Marsh Rd., Menlo Park, CA 94025; 800-876-3267, 415-321-9500, or fax 415-321-5471.
* Microsoft Corp., One Microsoft Way, Redmond, WA 98052-6399; 800-426-9400 or 206-882-8080.
* Novell Inc. 122 East 1700 South, Provo, UT 84606-6194; 800-453-1267, 801-429-7000, or fax 801-429-5155.
* Oracle Corp., Desktop Products Division, 400 Oracle Parkway, Redwood Shores, CA 94065; 800-633-0583 or 415-506-7000.
* Powersoft Corp. (a Sybase company) 561 Virginia Rd., Concord, MA 01742-2732; 800-273-2841, 508-287-1500, or fax 508-369-3997.
* Sylvain Faust Inc., 880 Boul. de la Carriére, Suite 120, Hull, Quebec, Canada J8Y 6T5; 800-567-9127 or 819-778-5045.

TABLE 1. Alphabet soup

CAECommon Applications Environment
CLIcall-level interface
CLSIDclass identifier
COMComponent Object Model
CORBAOMG's Common Object Request Broker Architecture
DAOData Access Objects
DCEOSF's Distributed Computing Environment
DOESunSoft's Distributed Objects Everywhere
GUIDglobally unique identifier
IDLInterface Definition Language
IIDinterface identifier
OCIOracle Call Interface
OCXOLE custom controls
ODLobject description language
OLEobject linking and embedding
OMGObject Management Group
OSFOpen Software Foundation
RPCremote procedure call
SCMService Control Manager
SOMIBM's System Object Model
TLBOLE type library
VBAVisual Basic for Applications
VBXVisual Basic extension

NILE: Microsoft's Data Integration Initiative

To improve access to heterogeneous data sources, Microsoft is developing "Nile." That is the working name for a high-level object interface that will integrate data from relational, network model, and hierarchical databases, as well as from flat files, spreadsheets, and other sources. On Microsoft platforms, Nile will act as a layer over COM services and lower-level technologies such as ODBC, which it will use for relational database access. Because it will be a high-level specification, theoretically, other vendors could implement Nile on non-Microsoft platforms using services available in those operating systems.

The need for a stable object interface for data access is apparent. Today, components and object interfaces lack the consistency to provide "plug-compatible" operation. For example, Novell's Visual AppBuilder Connection Object (an AppWare Loadable Module) may not behave like Intersolv Inc.'s MultiLink/VB Connect Control (a Visual Basic control) or like Sylvain Faust's SQL-Sombrero Connection Object (an OLE custom control). The purpose of an abstraction or object layer is to provide an interface to a virtual DBMS that maintains a stable interface, even if the underlying data sources change. Microsoft hopes that Nile will provide that stable interface, even when the underlying data does not reside in a DBMS.

As with OLE and ODBC, Microsoft plans to subject Nile to industry review before publishing it as an open specification. As a published spec, Nile is likely to move to multiple platforms, as we have seen recently with ODBC and OLE. In February 1995, Microsoft met with several dozen ISVs to review the first two sections of the draft. Reviews of the other sections were scheduled to follow soon thereafter. The Nile specification currently doesn't address the issue of integrating with a repository such as the one that Microsoft is developing with Texas Instruments. Also, Microsoft's initial review of Nile did not cover transaction processing, but later reviews will cover that topic.

--Ken North


--OLE is a layered architecture where OLE services such as In-Place Activation and Linking use lower level services such as Structured Storage. OLE builds on an infrastructure of services for Component Objects known as the Component Object Model.


--Windows Objects can expose multiple interfaces such as Interface A and Interface B. An object's interface (its methods or member functions) is accessible through virtual tables that contain a pointer to each member function. The data that the object encapsulates is not exposed to an object user.

Table 2. Applications use OLE 2.0 services by accessing these interfaces

Component Object Interfaces
IClassFactoryThe interface through which server and container applications create instances of an object class.
IEnumXIterates through an item list.
IExternalConnectionImplemented by DLL object applications to provide an orderly shutdown of object links.
IMallocUsed by OLE to allocate and free memory.
IMarshalProvides process space transparency of interface pointers for lightweight remote procedure calls.
IStdMarshalInfoReturns the class ID (CLSID) of the object handler that is to marshal data to and from the object.
IUnknownThe base interface that is common to all OLE applications.
Compound Document Interfaces
IAdviseSinkReceives asynchronous notifications from embedded or linked objects.
IAdviseSink2Receives notifications of link source changes.
IEnumOLEVERBEnumerates the verbs available for an object.
IOleAdviseHolderKeeps track of IOleObject::Advise calls and sends notification to registered links.
IOleClientSiteProvides services to an OLE object from its container.
IOleContainerEnumerates objects in a container.
IOleItemContainerUsed for binding item Monikers.
IOleObjectProvides a variety of member functions to manage OLE objects such as getting Monikers, CLSIDs, clipboard data, and so on.
IRunnableObjectIndicates to object handlers and DLL object applications when to run or become a contained object.
Data Transfer/Caching Interfaces
IDataAdviseHolderKeeps track of IDataObject::DAdvise calls and sends change notifications to object handlers and servers.
IDataObjectSupports format enumeration, data retrieval, transfers to and from objects, and notification of object changes.
IEnumFORMATETCEnumerates object data formats.
IEnumSTATDATAEnumerates an object's advisory connections.
IOleCacheControls the data cached inside an embedded object and determines the container's access to data when the object's server is unavailable.
IOleCache2Extends IOleCache to permit clients to update each of the maintained caches.
IOleCacheControlUsed by object handlers and DLL object applications to associate the cache part of the handler with the running object's IDataObject implementation.
IViewObjectProvides an object image or picture using a caller-specified device context.
IViewObject2An extension to IViewObject to provide containers and object handlers with the view extents of an object.
Linking Interfaces
IBindCtxThe bind context is used internally for purposes such as managing the list of bound objects.
IEnumMonikerEnumerates the Monikers of which an object is a part.
IMonikerAccesses and controls Monikers, and provides object binding.
IOleLinkProvides an interface for updating the Moniker inside a linked object and manipulating its update options.
IParseDisplayNameParses an object Moniker's display name.
IRunningObjectTableProvides an interface to the global inventory of currently running objects .
Structured Storage
IEnumSTATSTGUsed by OLE to enumerate IStorage objects.
ILockBytesSaves compound document objects to disk-based compound files, byte arrays, and custom storage such as relational databases.
IPersistObtains an object's CLSID. Parent of IPersistStorage, IPersistStream, IPersistFile.
IPersistFileUsed to load documents that reside in a file.
IPersistStorageProvides methods that containers can call to have a server load and save data.
IPersistStreamUsed to save and reload objects stored in a serial stream.
IRootStorage Switches the underlying disk file where objects are saved.
IStorageInstantiates a directory-like collection of storage and stream objects.
IStreamManipulates the underlying bytes of data that comprise an IStorage object.
Drag and Drop
IDropSourceProvides feedback and status information (for example, key state) to applications implementing drag-and-drop.
IDropTargetImplemented to communicate status (for example, key state and mouse location) with the drop source by applications that support dropped data.
In-Place Activation
IOleWindowContains methods that obtain the handle of the in-place window.
IOleInPlaceObjectActivates and deactivates an in-place object.
IOleInPlaceActiveObjectProvides communication between the in-place object and the frame and document windows.
IOleInPlaceUIWindowManipulates the container's document window.
IOleInPlaceFrameControls the application's top-level frame window.
IOleInPlaceSiteProvides an interface to the object's in-place client site.
Concurrency Management
IMessageFilterFilters Windows messages while waiting for responses from synchronous calls.
Programmable Controls
IOleControlUsed by a control to communicate with its container.
IOleControlSiteUsed on a container's site objects to communicate with a control.
IConnectionPoint Container Used to enumerate connection points for event dispatching.
IConnectionPoint Specifies a dispatch point for an event.
Source: Ken North's Windows Multi-DBMS Programming (John Wiley & Sons Inc., 1995).

Subscribe to DBMS and Internet Systems -- It's free for qualified readers in the United States
June 1995 Table of Contents | Other Contents | Article Index | Search | Site Index | Home

DBMS and Internet Systems (http://www.dbmsmag.com)
Copyright © 1995 Miller Freeman, Inc. ALL RIGHTS RESERVED
Redistribution without permission is prohibited.
Please send questions or comments to dbms@mfi.com
Updated Saturday, January 25, 1997