OLE: Microsoft Object Linking and Embedding

• OLE used to stand for Object Linking and Embedding, but not any more. Now it's just the word for Microsoft's high plug-in component infrastructure, built on top of the lower level COM framework.
• OLE and COM are essential parts of Win32.
• OLE Controls are part of OLE 2.0. The new version of OLE Controls is called ActiveX.
• Current features of OLE 2.0 include:
  • Structured Storage (Compound Documents)
  • Data Transfer
  • Drag and Drop
  • Naming and Binding
  • In-Place Editing
  • Programmability (OLE Automation)
• Uniform Data Transfer
  • Windows Clipboard and Drag and Drop are now implemented using OLE.
  • Implement Uniform Data Transfer interface once, and both cut & paste and drag & drop will work.
• Linking and Embeding
  • Linked Object: A pointer to data that is stored outside the document that contains the link. Easier to implement than an embedded object, but not as convenient for the user. Click on a link and bring up another program in a new window.
  • In Place Activation: Viewing or editing an embedded object using the source application's tools where those tools are made available inside the container application. The menus of the source application merge with the container application's menus. The toolbars for the source application appear, replacing the container application's toolbars.
  • Aggregation: the merging of menu options in a container application when an embeded object is activated for in-place editing. Also, toolbars are merged, but more standardization needs to take place.
  • OLE 2.0 allows linking to embedded objects, arbitrarily deep-nested linking, linking to files with absolute and relative path names, and linking to ranges (such as bookmarks or spreadsheet cells).
  • The following terms all mean the same thing: in-place editing, in-place activation, visual editing, in situ editing.
• OLE Automation
  • OLE Automation allows you to control one application from within another application's programming language.
  • It is the preferred way of doing interprocess communication, a replacement for the older DDE.
  • It competes with Open Scripting Architecture on the MacOS platform.
  • OLE Automation uses the IDispatch COM Interface: The means by which applications expose methods and properties such that other applications such as Visual Basic, or other languages, can make use of the application's features. OLE properties and interfaces can be reflected upon at runtime via the Type Library interface. The libraries are defined in the MIDL and ODL interface definition languages.
    • IDispatch::Invoke function: Most important part of IDisplatch interface.
    • Dispatch Maps: like Message Handler "Message Maps", and OLE "Interface Maps". Provides MFC with information about the layout or "shape" of your CCmdTarget derived classes, such that it can directly manipulate the properties of the object, or call member functions within your object to satisfy IDispatch::Invoke requests.
    • DISPID: Dispatch ID's. The end-user sees actual names of the automation enabled properties and methods, but IDispatch::Invoke uses these 32-bit magic cookies.
    • Visual C++ Class Wizard writes dispatch maps. Handles common cases, but not all.
      • DISP_FUNCTION: method definition
      • DISP_PROPERTY: member variable property access
      • DISP_PROPERTY_PARAM: get/set member functions
    • Class wizard does not support DISP_PROPERTY_NOTIFY and DISP_PROPERTY_PARAM, which you can code up by hand if you need to.
      • DISP_PROPERTY_NOTIFY: calls a notify function after the property changes.
      • DISP_PROPERTY_PARAM: calls parameterized getters and setters (like x,y params).
    • DISP_DEFVALUE: defines the default value.
    • DECLARE_OLECREATE, IMPLEMENT_OLECREATE: lets other automation clients create instances of a CCmdTarget-derived class.
    • COleDispatchDriver attaches to IDispatch interface objects, for type safe access.
  • COleVariant encapsulates VARIANT data type and polymorphic DISPPARAMS structure.
    • Type safe mechanism for passing data between automation servers and clients.
    • Tagged union with data and type tag.
    • Supports standard data types: 2 and 4 byte integers, 4 and 8 byte floats, strings, boolean, hresult error codes, currency, date, IUnknown, and IDispatch interfaces.
    • COleCurrency COleDateTime encapsulate variant data types CURRENCY (VT_CY) and DATE (VT_DATE). Used extensively in the DAO classes.
  • Automation clients can be dynamic or static.
    • Dynamic clients acquire information about properties and operations of the server dynamically at run time, using the IDispatch mechanism.
    • Static clients use information provided at compile time to specify the properties and operations of the server, using the COleDispatchDriver class. They use a "proxy class" that is statically linked with the client application, that provides a type safe C++ encapsulation of the server application's properties and operations. Use the ClassWizard to create a class derived from COleDispatchDriver, to support the static client side of OLE Automation.
• Structured Storage
  • Compount Document Management
  • Embedding a document inside another one, that's handled by a different OLE server program that its container.
  • Compound Files are structured similar to the file system with "Streams" (files) and "storages" (directories). Stream names can be as long as 32 characters. Each stream and storage is, in fact, an object and can be accessed through COM interfaces.
  • In structured storage, each component object can have its own stream, that it can read and write during its lifetime.
  • Structured storage supports "direct" and "transacted" modes of access. Direct access writes changes to storage immediatly. Transacted access buffers changes until commit or rollback, and supports undo. Performance of transacted access suffers because a snapshot has to be taken. However, direct access mode must open storage exclusively. Transacted access only applies to "storage" (directory) objects, not stream objects. All stream objects are opened in direct, and therefore exclusive, mode.
  • OLE spec defines special streams called "property sets" that conform to a standard layout, like the Summary Information field that contains information about a document's creator, etc.
  • OLE is implemented on the MacOS and Win32 platforms, and storage files are interchangeable across the different platforms.
• LRPC: Lightweight Remote Procedure Calls.
  • Takes care of marshaling parameters and interface calls from one process to another.
  • Even handles translations of calls between 16 bit and 32 bit environments.
  • You can change the subsystem from "lightweight remote procedure call" (LRPS) to "true remote procedure call" (RPC), compatible with Open Software Foundation's Distributed Computing Environment (OSF DCE).
• Monikers: Persistantly stored objects, used for link tracking. Store relative pathnames with the absolute pathnames. When the operating system eventually supports link tracking, you will be able to get to this service through the use of monikers. Until then, they partially solve the problem of link tracking.
• Metadata exposed through ITypeLibrary and related interfaces, describing COM interfaces, as well as OLE Automation interfaces (property types, function signatures, C++ classes, etc). These type libraries are defined in the MIDL and ODL interface definition languages.
• Alert Object Table: Defined by OLE 2.0 architecture, but not implemented. A list of objects and monikers that must be updated, when there are multiple editors on linked objects opened separately.
• OLE Controls are reusable embeddable automated user interface components implemented with OLE. They are implemented as auto-registering "Extension" DLLs, that have three entry points: to register and unregister the OLE objects implemented by the DLL, and a COM QueryInterface request to the "class factory", that will manufacture a new object that supports the requested COM interface, if it can.
• OLE provides no support for irregularly shaped objects, or objects that large objects that stradle the page boundary. (The OLE 2.0 specs claimed this "extended layout negotiation" would be supported, but it is not yet.) ActiveX supports irregularly shaped controls, now.
• Menu merging is supported. Toolbar negotiation is supported, but toolbars are not yet standardized.
• Many aspects of the Windows 95 Shell are implemented using OLE, like shortcuts and property sheets.
• NetScape Navigator documents can be embeded, and there is the nCompass plug-in that accepts embeded OLE components.
• Internet Explorer has OLE support of course. Microsoft is now refering to the next version of OLE as ActiveX.
• See also OBJECT embedding in HTML.
• See how DDE relates to OLE.
• How big is OLE 2.0? Windows version 1 had about 350 API functions. OLE 2 has over 100. So by measures of new functionality, OLE 2 is roughly one-third of an operating system. -Kraig Brockschmidt, Inside OLE 2.
• The Windows Registry is the database that keeps track of all the OLE servers, classes, objects, and properties.
• ODL files: Object Description Language. Different that IDL files (Interface Description Langauge). (which describes what? why two?)
• Document Objects (DocObjects) are the technology behind the Microsoft Binder application included in Office 95; both Word 7.0 and Excel 7.0 are DocObject servers. The advantage of DocObjects is that the server application, rather than the client, "owns" the frame within which the object appears. This feature improves the handling of frame adornments, allows multiple views of documents, and aids in printing object content. The principal use of DocObjects is displaying objects created with Microsoft Office 95 applications and other DocObject-enabled application, such as Visio 4.0, in Web pages. DocObjects are likely to appear in the next version of Microsoft's Internet Explorer. Get the lowdown on DocObject technology from http://www.microsoft.com/intdev/inttech/docobj.htm.
• WinInet is a distributable, 32 bit add-on Sweeper library (WININET.DLL) that provides operating system support for client-side internet functionality. WinInet will be incorporated in future versions of Windows 95 and Windows NT. The primary objective of the library is to eliminate the need to deal directly with TCP/IP, Internet protocols (such as FTP and HTTP), and Windows Sockets. Preliminary spec: http://www.microsoft.com/intdev/inttech/wininet.htm.
• Internet Control Pack is a set of OLE controls (aka ActiveX components) providing access to the WinInet functions of adding Web browsing, newsgroup reading, and FTP capabilities to applications created with VB4 and Access 95, plus other OLE 2.x client applications that can act as OLE control containers. Providing an OCX wrapper around the WinInet functions eliminated the need to declare function prototypes and takes care of callback problems. Updates to Microsoft Access and Visual FoxPro will provide easy Web access to data stored in Jet MDB and FoxPro DBF databases.