OLE with .NET - Part 1

OLE with .NET - Part 1

This topic will give you an overview of the concepts, as well as the use cases that related to OLE in Excel with the .NET platform.

What is OLE?

  • OLE, short for Object Linking & Embedding, is a proprietary technology developed by Microsoft that allows embedding and hyperlinks with documents and other objects. For developers, it offers OLE Control Extension (OCX), which is a way to develop and use custom user interface elements. At the technical level, an OLE object is any object that implements the IOleObject interface, possibly along with a range of other interfaces, depending on the needs of the object.


  • OLE allows an editing application to export a part of a document to another editing application and then import it with additional content. For example, a desktop publishing system can send some text to a Word processor or image to a bitmap editor using OLE. The main benefit of OLE is the ability to add different types of data to a document from different applications, such as text editors and image editors. This feature creates a compound binary file format document and a master file for which the document makes references. Changing the data in the main file immediately affects the reference to it. This is called "linking" (instead of "embedding").
  • Its primary uses are for managing compound binary file formats and transferring data between different application software using drag and drop and clipboard.

The history of OLE

OLE 1.0

  • OLE 1.0, released in 1990, is a development of the original Dynamic Data Exchange (DDE) concept that Microsoft developed for previous versions of Windows. Although DDE is limited in transferring a limited amount of data between two running applications, OLE can maintain active links between two documents or even embed one type in another.
  • OLE clients and servers communicate with system libraries using virtual function boards or VTBL. VTBL includes a structure of function pointers that the system library can use to communicate with the server or client. The client and server libraries, OLESVR.DLL and OLECLI.DLL, were initially designed to deliver between them using the WM_DDE_EXECUTE message.
  • Later, OLE 1.0 evolved to become an architecture for software components called Component Object Model-COM, and DCOM.
  • When we embed an OLE object in a document, or sometimes placed on the clipboard, both visual representations in native Windows formats (bitmap or metafile) are stored, as well as the underlying data as specified. This rule allows the application to display the object without loading the application used to create the object, and also allows us to edit the object if we installed the appropriate app.
  • Object Packager, a component of OLE, included in Windows 3.1 through Windows XP allows a non-OLE object to be "packaged" so that OLE client programs can embed these "packaged."

OLE 2.0

  • OLE 2.0 is the next generation of OLE, sharing many of the same goals as version 1.0, but has been redeployed on the Component Object Model (COM) instead of using VTBL directly. New features are OLE automation, drag and drop, on-premises activation, and structured storage. Nicknames evolve from OLE 1 object names and provide a hierarchical object and resource naming system similar to URLs. Windows now incorporates two technologies that support the Moniker URL type and the Moniker URL scheme.

OLE custom controls

  • The world first knew about the OLE custom controls in 1994 as an alternative to the deprecated Visual Basic Extension controls (VBA). Instead of upgrading them, people have used OLE to develop new architecture. Correctly, any container that supports OLE 2.0 can embed custom OLE controls, although these controls cannot respond to events unless the container supports this. We usually ship OLE custom controls as dynamic link library extensions.ocx. In 1996, the manufacturer has turned all consoles (except IUnknown) optional to keep the file size of the control reduced, so that they would download faster; These are called ActiveX Controls.


  • Component Object Model implements these OLE objects and containers; they are objects that can implement interfaces to export their functions. Only the IOleObject interface is required, but we may also need to perform other interfaces if the functionality that is transported by those interfaces is required. To better understand what is said below, some terms need to be clarified. The view state of the object is whether the object is transparent, opaque, or opaque to a homogeneous background and whether the object supports drawing with a specified aspect. The page of an object is an object that represents the position of the object in its container. A container supports the storage of objects for all objects. The following is a list of interfaces, grouped by the object they usually need to implement. Interfaces often implemented by OLE objects are often called by OLE containers and vice versa. Note that the following indented list indicates the inheritance of the interface.
  • IUnknown provides all non-indented interfaces.

OLE object

  • When deployed, it allows data transfer and data change notification.
  • Allow callers to notify OLE objects of its website. OOOject also provided this functionality, but we cannot use ObjectWithSite when supported, if we do not use OleObject for other things.
  • Allow visual display from stored DataObject. This visual display allows embedded objects to store their visual representation, therefore allowing it to be displayed later without having to launch the application that creates the object.
  • Usually, the implementation will retrieve the content stored in the object.
  • OleCache2
  • Provides more precise control in caching.
  • Usually, the implementation will retrieve the content stored in the object.
  • We won't call this interface by the container but will call it by the internal of the object that allows it to receive notifications when the DataObject is running. Thus, this will also allow it to register notifications of that object's data change and therefore allow it to update the cached presentation properly.
  • Usually, the implementation will retrieve the content stored in the object.
  • Enables the OLE object to support its multiple data views, as well as several related functions.
  • A document object (an OleDocument implementation object) implements this interface for each request to view the object. It allows callers to set the page of the object, query and set the size of the object and to display and activate it, as well as several related functions.
  • OleInPlaceActiveObject
  • Called by the outermost container of an object to interact with it while it is active, for example, to handle acceleration keys in the message queue of the container meant for the container object.
  • OleInPlaceObject
  • Called by the container to activate or deactivate the object.
  • An object without a window is a windowless object and will display in the window of its container. It is used by the container to forward messages received by the container window designed for the container object. For example, if we move the cursor over a window screen, Windows places a mouse movement notification along with the mouse coordinates in the window's message queue. If this window contains any windowless embedded object, the message may have to be forwarded to such an object if the mouse pointer coordinates are on the object. For the same reason, this interface also provides access to the object's DropTarget interface.
  • Allow the object to support binding, for example, by allowing the container to place the source of the associated object. Usually, the deployment will get the deployment content cached in the object.
  • Arguably this is the most crucial interface for an OLE object. For example, it allows the container to notify its object, initialize the object from the data, open and close it, to query or set the object's size, request notification on the container's AdviseSink and Show objects that have been defined as verbs on the object. These verbs often include Open or Edit, but can also add other verbs. We describe one of the verbs as the main verb and will perform it when the user double clicks on an object.

Lets an object draw itself directly, without moving a DataObject into the container. For those objects that support both DataObject and this interface, we often see that sharing is widespread between the following deployment commands.

  • ViewObject2
  • Allows callers to query the size of the object.
  • ViewObjectEx
  • Add support for flicker-free display of transparent objects, experiment with irregularly shaped objects, and set the size of an object.

And that is an overview of OLE. In the next part, we will dive into the OLE use cases with the .NET platform. Stay tuned for more.

45-Day Money Back Guarantee

We will refund your full money in 45 days
if you are not satisfied with our products

Buy Now
You have successfully subcribed to our mailing list.
Dont miss out Get update on new articles and other opportunities Subscribe