Object Linking and Embedding

Last updated

Object Linking and Embedding (OLE) is a proprietary technology developed by Microsoft that allows embedding and linking to documents and other objects. For developers, it brought OLE Control Extension (OCX), a way to develop and use custom user interface elements. On a technical level, an OLE object is any object that implements the IOleObject interface, possibly along with a wide range of other interfaces, depending on the object's needs.

Contents

Overview

OLE allows an editing application to export part of a document to another editing application and then import it with additional content. For example, a desktop publishing system might send some text to a word processor or a picture to a bitmap editor using OLE. The main benefit of OLE is to add different kinds of data to a document from different applications, like a text editor and an image editor. This creates a Compound File Binary Format document and a master file to which the document makes reference. Changes to data in the master file immediately affect the document that references it. This is called "linking" (instead of "embedding").

OLE is also used for transferring data between different applications using drag and drop and clipboard operations.

History

OLE 1.0

OLE 1.0, released in 1990, was an evolution of the original Dynamic Data Exchange (DDE) concept that Microsoft developed for earlier versions of Windows. While DDE was limited to transferring limited amounts of data between two running applications, OLE was capable of maintaining active links between two documents or even embedding one type of document within another.

OLE servers and clients communicate with system libraries using virtual function tables, or VTBLs. The VTBL consists of a structure of function pointers that the system library can use to communicate with the server or client. The server and client libraries, OLESVR.DLL and OLECLI.DLL, were originally designed to communicate between themselves using the WM_DDE_EXECUTE message.

OLE 1.0 later evolved to become an architecture for software components known as the Component Object Model (COM), and later DCOM.

When an OLE object is placed on the clipboard or embedded in a document, both a visual representation in native Windows formats (such as a bitmap or metafile) is stored, as well as the underlying data in its own format. This allows applications to display the object without loading the application used to create the object, while also allowing the object to be edited, if the appropriate application is installed.

The Object Packager, a component of OLE, shipping from Windows 3.1 up to Windows XP allows a non-OLE object to be "packaged" so it can be embedded into an OLE client.

OLE 2.0

OLE 2.0 was the next evolution of OLE, sharing many of the same goals as version 1.0, but was re-implemented on top of the COM instead of using VTBLs directly. New features were OLE automation, drag-and-drop, in-place activation and structured storage. Monikers evolved from OLE 1 object names, and provided a hierarchical object and resource naming system similar to URLs or URIs, which were independently invented. Windows now has merged the two technologies supporting a URL Moniker type, and a Moniker URL scheme.

OLE custom controls

OLE custom controls were introduced in 1994 as a replacement for the now deprecated Visual Basic Extension controls. Instead of upgrading these, the new architecture was based on OLE. In particular, any container that supported OLE 2.0 could already embed OLE custom controls, although these controls cannot react to events unless the container supports this. OLE custom controls are usually shipped in the form of a dynamic link library with the .ocx extension. In 1996 all interfaces for controls (except IUnknown) were made optional to keep the file size of controls down, so they would download faster; these were then called ActiveX Controls.

Technical details

OLE objects and containers are implemented on top of the Component Object Model; they are objects that can implement interfaces to export their functionality. Only the IOleObject interface is compulsory, but other interfaces may also need to be implemented if the functionality exported by those interfaces is required.

To ease understanding of what follows, some terminology has to be explained. The view status of an object is whether the object is transparent, opaque, or opaque with a solid background, and whether it supports drawing with a specified aspect. The site of an object is an object representing the location of the object in its container. A container supports a site object for every object contained.

What follows is a list of interfaces, grouped by the object that usually needs to implement them. Interfaces usually implemented by the OLE object are usually called on by the OLE container, and vice versa. Note that in the following list indentation indicates interface inheritance. All non-indented interfaces derive from IUnknown .

OLE object

DataObject
When implemented, enables the transfer of data, and notification of data changes. It must be implemented by objects that are to support drag-and-drop, being copied to or pasted from the clipboard, or being linked or embedded in a containing document.
ObjectWithSite
Allows the caller to inform the OLE object of its site. This functionality is also provided by OleObject, but ObjectWithSite can be used, when supported, if OleObject is not used for other matters.
OleCache
Allows visual presentations from a DataObject to be cached. This allows an embedded object to store its visual representation, thus enabling it to be displayed later without needing to start the application that was used to create the object.
Usually the stock implementation is used.
OleCache2
Provides more fine-grained control over caching.
Usually the stock implementation is used.
OleCacheControl
This interface is not called by the container, but internally by the object to allow it to receive notifications of when its DataObject is running, thereby allowing it to subscribe to notifications of data changes of that object and thus allowing it to update the cached presentation properly.
Usually the stock implementation is used.
OleDocument
Allows the OLE object to support multiple views of its data, as well as a few related functions.
OleDocumentView
A document object (an object that implements OleDocument) implements this interface for every view. It allows the caller to set the site of the object, query and set the size of the object and to show and activate it, as well as some related functions.
OleWindow
OleInPlaceActiveObject
Called by the outermost container of an object to interact with it while it's active, e.g. to process accelerator keys in the container's message queue that are meant for the contained object.
OleInPlaceObject
Called by the container to activate or deactivate the object.
IOleInPlaceObjectWindowless
A windowless object is an object that doesn't have its own window but it instead displayed in its container's window. It is used by the container to relay messages received by the container's window that are intended for the contained object. For example, if the mouse is moved over a window, Windows places a mouse move message along with the mouse coordinates in the message queue of the window. If this window contains windowless embedded objects, the message may have to be relayed to such an object if the coordinates of the mouse-pointer are over this object. For similar reasons this interface also provides access to the object's DropTarget interface.
OleLink
Allows the object to support linking, e.g. by allowing the container to set the source of a linked object.
Usually the stock implementation is used.
OleObject
Arguably the most important interface for an OLE object. For example, it allows the container to inform the object of its site, initialize the object from data, to open and close it, to query and set the size of the object, to ask for notifications on the container's AdviseSink and to execute objects defined as "verbs" on the object. These verbs often include "Open" or "Edit", but can also include other verbs. One of the verbs is defined to be the principal verb, and it is executed when the user double-clicks an object.
ViewObject
Allows an object to draw itself directly, without passing a DataObject to the container. For objects that support both DataObject and this interface, the underlying implementation is usually shared.
ViewObject2
Additionally allows the caller to query the size of the object.
ViewObjectEx
Adds support for flicker-free drawing of transparent objects, hit-testing for objects with irregular shapes and setting the size of an object.

OLE container

IAdviseSink
Allows the implementer to receive notifications when the object is saved, closed, or renamed, or when its data or visual presentation changes.
IAdviseSink2
Additionally allows the implementer to receive notifications when the link source of the OLE object changes.
IAdviseSinkEx
Additionally allows the implementer to receive notifications when the view status of the OLE object changes.
IOleClientSite
This interface allows the caller to obtain information on the container and location of an object, as well requesting that the object be saved, resized, shown, hidden, et cetera.
IOleDocumentSite
Allows the caller to ask for the object on this site to be activated immediately. If this interface is implemented, IOleClientSite, IOleInPlaceSite and IAdviseSink must be implemented as well.
IOleContainer
This interface allows the caller to enumerate embedded objects in a container, or to find such objects by name. It is primarily useful if the container wishes to support links to embedded objects.
IOleWindow
IOleInPlaceUIWindow
Enables embedded objects to negotiate space for toolbars on the container's window.
IOleInPlaceFrame
Allows the caller to ask the container to insert its menu items in an empty menu that will become the cooperative menu. Also allows the caller to ask the container to show or hide this menu, to show or hide dialog boxes, and to process accelerator keys received by the contained object intended for the container.
IOleInPlaceSite
If a container implements this interface, it allows embedded objects to be activated in place, i.e. without opening in a separate window. It provides access to the container's IOleInPlaceUIWindow.
IOleInPlaceSiteEx
If a container implements this interface, it allows embedded objects to check whether they need to redraw on activation or deactivation. It also allows them to request their UI to activate.
IOleInPlaceSiteWindowless
If a container wishes to support windowless embedded objects, it needs to provide functionality to embedded objects to replace the functionality normally provided by an embedded object's window. For example this interface provides a way to access the container's window's device context, thereby enabling the embedded object to draw in the container's window.
IOleUILinkContainer
Contains the methods that the standard OLE dialog boxes that manage linked objects use to update linked objects in a container, or to query and change their sources. Used by the "Links", "Change source", "Update links" and "Object properties" dialog boxes.
IOleUILinkInfo
Additionally allows the dialog boxes to query when linked objects were last updated, and whether this was done automatically or manually.
IOleUIObjInfo
Contains the methods needed by the "Object properties" dialog box. For example if the user opens the "Object properties" dialog box and asks for the object to be converted to another type, a method on this interface is called.
IOleUndoManager
Provides a centralized undo service to both the container itself and to embedded objects. When an undoable action is performed, an IOleUndoUnit is created and added to the IOleUndoManager

Other

IDataAdviseHolder
The methods of IDataObject that pertain to data change notifications can be implemented by calling the methods of this interface.
Usually the stock implementation is used.
IOleAdviseHolder
The methods of IOleObject that pertain to notifications can be implemented by calling the methods of this interface.
Usually the stock implementation is used.
IDropSource
Implemented by objects that can be dragged, i.e. that can be the source of a drag-and-drop operations. When implemented it allows the object to draw drag-and-drop effects, and to specify when the object is dropped, or the drag-and-drop operation is cancelled.
IDropTarget
Implemented by objects that accept dropped objects, i.e. that can be the target of drag-and-drop operations. When implemented it allows the target to specify if a dropped object will be accepted, and what happens to an object after it is dropped.
IOleCommandTarget
Can be implemented by objects (OLE objects, OLE containers, and other objects) that wish to support certain standard commands. It allows callers to query if commands are supported, and to execute commands. Commands that an object might typically wish to implement may include things like "delete", "cut", "copy", "paste", "undo", "find", "print", "save", "zoom", and so on. Currently 58 standard commands have been defined, and they include commands commonly used by office software, web browsers and similar applications.
IOleUndoUnit
Represents an action that can be undone. It contains all information necessary to undo an action. It is created by objects and containers, so that undoable actions can be added to the container's IOleUndoManager.
IOleParentUndoUnit
Allows an undo unit to contain other undo units. In essence this allows the undo unit to act as an undo stack, grouping undo units together. For example, if a macro is run, all undo-able actions performed by the macro may be grouped together in one undo unit.
IOleWindow
This interface represents a window of a container or contained object. It allows callers to obtain the handle of the window, and to toggle the context-sensitive help function. When the context-sensitive help function is turned on, typically the mouse-pointer changes to an arrow with a question mark to indicate that clicking a user interface element will result in opening a help window.

Competition

OpenDoc technology tried to compete with OLE. Some of Microsoft's competitors considered OpenDoc to be more robust and easier to use; however, OpenDoc does have some known problems. OpenDoc allowed users to view and edit information across applications, directly in competition with Microsoft's proprietary OLE standard. In 1993 some Microsoft competitors established a consortium called the Component Integration Laboratories ("CIL") to develop OpenDoc as an open standard for cross-platform linking and embedding.

Microsoft required OLE compatibility as a condition of Microsoft's certification of an application's compatibility with Windows 95. Microsoft initially announced that applications using OpenDoc would be deemed compatible with OLE, and would receive certification for Windows 95. Microsoft later reversed the decision and said that applications using OpenDoc might not receive certification at all. Microsoft withheld specifications and debugged versions of OLE until after it had released its competing applications.

Interoperability

Use of OLE objects limits interoperability, because these objects are not widely supported in programs for viewing or editing files outside of Microsoft Windows (e.g., embedding of other files inside the file, such as tables or charts from a spreadsheet application in a text document or presentation file). [1] [2] [3] [4] If software that understands an OLE object is not available, the object is usually replaced by a picture (bitmap representation of the object) or not displayed at all. [5] [6] [7]

See also

Related Research Articles

The Rich Text Format is a proprietary document file format with published specification developed by Microsoft Corporation from 1987 until 2008 for cross-platform document interchange with Microsoft products. Prior to 2008, Microsoft published updated specifications for RTF with major revisions of Microsoft Word and Office versions.

VBScript is a deprecated Active Scripting language developed by Microsoft that is modeled on Visual Basic. It allows Microsoft Windows system administrators to generate powerful tools for managing computers without error handling and with subroutines and other advanced programming constructs. It can give the user complete control over many aspects of their computing environment.

Visual Basic for Applications (VBA) is an implementation of Microsoft's event-driven programming language Visual Basic 6.0 built into most desktop Microsoft Office applications. Although based on pre-.NET Visual Basic, which is no longer supported or updated by Microsoft, the VBA implementation in Office continues to be updated to support new Office features. VBA is used for professional and end-user development due to its perceived ease-of-use, Office's vast installed userbase, and extensive legacy in business.

<span class="mw-page-title-main">ActiveX</span> Software framework by Microsoft introduced in 1996

ActiveX is a deprecated software framework created by Microsoft that adapts its earlier Component Object Model (COM) and Object Linking and Embedding (OLE) technologies for content downloaded from a network, particularly from the World Wide Web. Microsoft introduced ActiveX in 1996. In principle, ActiveX is not dependent on Microsoft Windows operating systems, but in practice, most ActiveX controls only run on Windows. Most also require the client to be running on an x86-based computer because ActiveX controls contain compiled code.

In computing, Open Database Connectivity (ODBC) is a standard application programming interface (API) for accessing database management systems (DBMS). The designers of ODBC aimed to make it independent of database systems and operating systems. An application written using ODBC can be ported to other platforms, both on the client and server side, with few changes to the data access code.

<span class="mw-page-title-main">OpenDoc</span> Software componentry framework standard

OpenDoc is a defunct multi-platform software componentry framework standard created by Apple in the 1990s for compound documents, intended as an alternative to Microsoft's proprietary Object Linking and Embedding (OLE). It is one of Apple's earliest experiments with open standards and collaborative development methods with other companies. OpenDoc development was transferred to the non-profit Component Integration Laboratories, Inc., owned by a growing team of major corporate backers and effectively starting an industry consortium. In 1992, the AIM alliance was launched by Apple, IBM, and Motorola, with OpenDoc as a foundation. With the return of Steve Jobs to Apple, OpenDoc was discontinued in March 1997.

An object-oriented operating system is an operating system that is designed, structured, and operated using object-oriented programming principles.

The taskbar is a graphical user interface element that has been part of Microsoft Windows since Windows 95, displaying and facilitating switching between running programs. The taskbar and the associated Start Menu were created and named in 1993 by Daniel Oran, a program manager at Microsoft who had previously collaborated on great ape language research with the behavioral psychologist B.F. Skinner at Harvard.

In computer programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The COM specification mandates that COM objects must implement this interface. Furthermore, every other COM interface must be derived from IUnknown. IUnknown exposes two essential features of all COM objects: object lifetime management through reference counting, and access to object functionality through other interfaces.

Open Platform Communications (OPC) is a series of standards and specifications for industrial telecommunication. They are based on Object Linking and Embedding (OLE) for process control. An industrial automation task force developed the original standard in 1996 under the name OLE for Process Control. OPC specifies the communication of real-time plant data between control devices from different manufacturers.

Netscape Plugin Application Programming Interface (NPAPI) is a deprecated application programming interface (API) for web browser plugins, initially developed for Netscape Navigator 2.0 in 1995 and subsequently adopted by other browsers.

Windows Presentation Foundation (WPF) is a free and open-source graphical subsystem originally developed by Microsoft for rendering user interfaces in Windows-based applications. WPF, previously known as "Avalon", was initially released as part of .NET Framework 3.0 in 2006. WPF uses DirectX and attempts to provide a consistent programming model for building applications. It separates the user interface from business logic, and resembles similar XML-oriented object models, such as those implemented in XUL and SVG.

<span class="mw-page-title-main">Microsoft Data Access Components</span> Framework

Microsoft Data Access Components is a framework of interrelated Microsoft technologies that allows programmers a uniform and comprehensive way of developing applications that can access almost any data store. Its components include: ActiveX Data Objects (ADO), OLE DB, and Open Database Connectivity (ODBC). There have been several deprecated components as well, such as the Jet Database Engine, MSDASQL, and Remote Data Services (RDS). Some components have also become obsolete, such as the former Data Access Objects API and Remote Data Objects.

In Microsoft Windows applications programming, OLE Automation is an inter-process communication mechanism created by Microsoft. It is based on a subset of Component Object Model (COM) that was intended for use by scripting languages – originally Visual Basic – but now is used by several languages on Windows. All automation objects are required to implement the IDispatch interface. It provides an infrastructure whereby applications called automation controllers can access and manipulate shared automation objects that are exported by other applications. It supersedes Dynamic Data Exchange (DDE), an older mechanism for applications to control one another. As with DDE, in OLE Automation the automation controller is the "client" and the application exporting the automation objects is the "server".

COM Structured Storage is a technology developed by Microsoft as part of its Windows operating system for storing hierarchical data within a single file. Strictly speaking, the term structured storage refers to a set of COM interfaces that a conforming implementation must provide, and not to a specific implementation, nor to a specific file format. In addition to providing a hierarchical structure for data, structured storage may also provide a limited form of transactional support for data access. Microsoft provides an implementation that supports transactions, as well as one that does not.

OLE DB for OLAP is a Microsoft published specification and an industry standard for multi-dimensional data processing. ODBO is the standard application programming interface (API) for exchanging metadata and data between an OLAP server and a client on a Windows platform. ODBO extends the ability of OLE DB to access multi-dimensional (OLAP) data stores.

ActiveX Document is a Microsoft technology that allows users to view and edit Microsoft Word, Excel, and PDF documents inside web browsers. It defines a set of Component Object Model coding contracts between hosting programs like Internet Explorer or Microsoft Office Binder and hosted documents from programs like Microsoft Word, Microsoft Excel and Adobe Reader. This allows them to negotiate communications about commands like save and navigate, as well as merging user interface elements such as menu, to provide a unified user experience.

The Text Object Model (TOM) is a Microsoft Windows API that provides developers with object-based rich text manipulation interfaces. It is implemented through COM, and can be accessed through Microsoft Word or additionally through the RichEdit controls that normally ship with Windows.

Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication (IPC) object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime.

Microsoft Office shared tools are software components that are included in all Microsoft Office products.

References

  1. ↑ Byfield, Bruce (2005-08-23). "FOSS word processors compared: OOo Writer, AbiWord, and KWord". Linux.com. The Linux Foundation. Archived from the original on 2020-11-06. Retrieved 2020-09-29.
  2. ↑ Byfield, Bruce (2005-07-28). "Sharing files between OpenOffice.org and Microsoft Office". Linux.com. The Linux Foundation. Archived from the original on 2020-11-06. Retrieved 2020-09-29.
  3. ↑ Sharma, Mayank (2008-11-20). "SoftMaker Office 2008 focuses on compatibility with Microsoft Office". Linux.com. The Linux Foundation. Archived from the original on 2020-11-06. Retrieved 2020-09-29.
  4. ↑ Lagadec, Philippe (2006-11-30). "OpenOffice / OpenDocument and Microsoft Office 2007 / Open XML security" (PDF). PacSec 2006 Conference. Archived (PDF) from the original on 2011-07-22. Retrieved 2020-09-29.
  5. ↑ Gong, Rhett (2005-09-05). "RE: OLE object - bitmap representation?". Newsgroup:  microsoft.public.win32.programmer.ole. Usenet:   iZFkEiesFHA.1204@TK2MSFTNGXA01.phx.gbl . Retrieved 2020-09-29.
  6. ↑ O'Neill, Mike (2005-02-09). "A Rich Edit Control That Displays Bitmaps and Other OLE Objects". Code Project. Archived from the original on 2011-12-31. Retrieved 2020-09-29.
  7. ↑ "ACC: Why OLE Objects Cause Databases to Grow". Microsoft. 2007-01-19. Archived from the original on 2008-02-15.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.