OPC 5 – Object Linking and Embedding OLE

We’ve talked a bit about the deficiencies of DDE for transferring data between applications in Windows (IPC – InterProcess Communications).

Microsoft attempted to fix this problem by introducing Object Linking and Embedding (OLE) technology in the early 1990s. As the name implies OLE provided two things, Object Linking – the ability to reference data in a file instead of containing data in the file and Object Embedding – the ability to contain a “foreign” object in a file.

Linking allowed data to be referenced in multiple places. A master copy of the data could maintain the current data values and when the other applications were executed they could link to and object the most recent copy of the data. Embedding, for the first time, actually allowed a visualization not supported by an application (sound file in a document file) to be opened and edited by invoking the native package for that object. These capabilities dramatically changed the landscape for Windows IPC. Applications grew in functionality and complexity on a scale never imagined just a few years earlier.

OLE provided far more functionality than DDE for interprocess communication. It allowed Windows developers to create far more complex and interesting applications by using the platforms inherent in Windows:
• Excel for charting and trending
• Word for reporting and document generating
• Visual Basic and Visual C++ for user interfaces

The key item that OLE provided over DDE was an object oriented approach to sharing data between software modules in a system. With DDE everything was single point oriented. OLE expanded the interface to provide for properties, methods and events.
For example, if Excel was the OLE Server, you could access:
iFillColor = ActiveCell.Interior.Color (Get a property of a cell)
Range(Cells(1, 1), Cells(1, 1)).AutoFit (Execute a method on a range of cells)
Private Sub Worksheet_Change(…) (Execute a sub procedure based on an event)

In this object oriented system the developer had an amazing palette of functionality that could be accessed from a Client process, far exceedin anything available with DDE.

One of the first places to use this technology was to bring data into an application from some plant floor device. The data and controls for this hardware could be encapsulated as a set of properties, methods and events and made available to an application module.

OLE Servers like this, with the ability to control some external device, and “plugged” into an application were termed OLE Controls (OCXs as their extension was .ocx). Any application with the capability to access OLE interfaces could host an OLE control and communicate with one or more external devices. Very cool in its day.

If you’re new to the industrial controls world in the last ten years, I can’t tell you how revolutionary this was. It set the stage for a massive shift in the ability of developers to create Windows applications for the factory floor.

Later on these OLE Controls became independent of a host. They became a registered component of windows and were available to all who might want to use their services. And that, my friends, was the beginning of the next revolution…