Object Linking and Embedding (OLE)

Object Linking and Embedding is that the full form of OLE. It has been invented by Microsoft during the implementation of MS Office to embed the functionality of other office file inside another sort of file. Like embed an Excel spread sheet in side a word document or vice versa.

OLE Control eXtension (OCX) is a gift came out of OLE for developers. It brought the design on how to develop and use custom interface elements. On technical point of view, an OLE object is any object that implements the IOleObject interface. It is possibly along side a good range of other interfaces, counting on the object's needs.

Overview (OLE)

As the name "Object linking and Embedding" suggests, it allows an editor to embed part of a document to another editor and then re-import it. 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 using OLE is to display visualizations of data from other programs that the host program is not normally able to generate itself (e.g. a pie-chart in a text document), as well as to create a master file. References to data in this file can be made and the master file can then have changed data which will then take effect in the referenced document. This is called "linking" (instead of "embedding").

Its primary use is for managing compound documents, but it is also used for transferring data between different applications using drag and drop and clipboard operations. The concept of "embedding" is also central to much use of multimedia in Web pages, which tend to embed video, animation (including Flash animations), and audio files within the hypertext markup language (such as HTML or XHTML) or other structural markup language used (such as XML or SGML) - possibly, but not necessarily, using a different embedding mechanism than OLE...

History (OLE)

OLE 1.0 - OLE 1.0, released in 1990, was the evolution of the original dynamic data exchange, or DDE, concepts 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 1.0, sharing many of the same goals, but was re-implemented on top of the Component Object Model instead of using VTBLs directly. New features were automation, drag-and-drop, in-place activation and structured storage. Monikers evolved from OLE 1 object names, and provided an 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. Today Microsoft's Internet Explorer uses the operating system's URL Monikers internally to download resources. Applications which do so can share IE's cache. However most (if not all) competing browsers have a completely independent implementation of Web protocols, including their own cache, and do not use the Moniker system.
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)

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 need to be implemented as well if the functionality exported by those interfaces is required.
To ease understanding of what follows, a bit of 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.

About our authors: Team EQA

You have viewed 1 page out of 67. Your COM/DCOM learning is 0.00% complete. Login to check your learning progress.