In a strange sequence of events over the past week, I was asked to put together a proposal to support Microsoft’s OLE (Object Linking and Embedding) technology for a web-based tool set. For those of you wondering what OLE is used for, it is the enabling technology that allows you to copy and paste bits of content from one application to another while still being able to use that content from the original application. For example when you copy/paste a graph from Excel into a Word document but you can still edit the graph in Excel (it isn’t just a picture), either “in-place” (i.e. – use the Excel interface while you are still in Word) or “out of place” (i.e. – use the Excel interface in its own window but when you close Excel your updates magically appear in the original Word document). All of that happens using OLE. And there is a lot going on behind the scenes to keep track of it all.

It’s an area in which I have a significant amount of practical expertise so it wasn’t that much of a surprise that I was asked about it, but as I did the research on what would be needed to put it all together, I started to think (again) about why this difficult infrastructure is still in use. With .Net and all of the other technologies that Microsoft has rolled out as their next generation platform, OLE persists and is becoming more and more difficult to support as C++ continues its steep decline as a language of choice.

In my opinion, the key point that will eventually force Microsoft to support OLE into the future is the user experience. When implemented properly OLE is an absolutely fantastic user experience. You can embed all sorts of content from all sorts of specialized applications into your daily productivity tools, generally Word, Excel and PowerPoint, and it all “just works” when you click on it, putting you in the best environment for the job of editing the content in question. And Windows users have come to expect their programs to work that way. Taking this piece of workflow optimization that has become such a key part of how people work is not going to be easy.

Most of the documentation that is written by Microsoft on this suggests that the AxHost object can be used to host ActiveX controls as a workaround to writing C++ code to support OLE, because OLE is not supported in any .Net language (C#, VB, etc.) but AxHost is incredibly buggy and there are all sorts of issues with window focus and other minutiae. Basically, it’s a non-starter in terms of a solution and the best example of this is that the OLE support in the Office apps is all still written in C++.

So I think OLE will persist because users will demand it and software developers will be pressed to continue to find ways of supporting it. It certainly seems like I will be refreshing my knowledge on the subject. I’d be interested to hear what other developers/architects/etc. think of this. And if you need some help with OLE.. just let me know.

Jeff Carter | jeff@cartercp.com
Principal, Carter Consulting Partners