Skolob Matrix - Since 1996

Welcome to the Skolob Matrix. This is place on the web that has been long forgotten.

Windows Programming : OLE Automation (Guide)

skolob | 17 September, 2007 15:35

(December 1998)


The purpose of this report is to determine the problems associated with implementing Object Linking and Embedding (OLE) Automation features into a software product, giving the reader an introduction to OLE Automation.

Common OLE Automation implementation problems are first discussed with examples of each given.

Solutions to these implementation problems are then explored and analyzed.


OLE Automation is a feature that allows common users to write simple programs that control larger, third-party applications that support OLE Automation.

A variety of problems can occur with the implementation of OLE Automation in an application, starting at a high-level and eventually infesting the entire application.

Practical solutions to these implementation problems include better developer education about OLE Automation and more efficient planning on how to implement OLE Automation.


An effective implementation of OLE Automation begins before any code is actually written, when programmers should be educated as to how OLE Automation works and have input as to how it will be implemented in the project.

In the actual development stage the developers should share the work of applying OLE Automation with one person leading the group instead of all of OLE Automation being lumped to one person.

Another efficient development step is to have the developers use methods common to all code for OLE Automation, thus reducing code maintenance and bug potential.


In the computer industry today applications exist for almost every conceivable user need. However, if a user wanted to use parts of one application in another (ie. use a graph created in a spreadsheet in a word processing package) then until 1992 this could not be done. It was at this time that Microsoft created the Object Linking and Embedding (OLE) stream of programming functions that allowed programmers to create applications for users that allowed one large document to consist of a variety of smaller documents, each created in a different application.

A subset of the OLE concept was known as OLE Automation. In short, OLE Automation allows program developers to expose certain program components (or objects) so that these can be manipulated by Visual Basic users to create large custom applications that consist of a variety of smaller, third-party applications (each of which is accessed via these exposed objects). This definition becomes clearer through an example: Consider a person with not alot of programming experience who needs to create a small application that with one mouse button click will launch a word processor and with another mouse button click will launch a spreadsheet application. Before OLE Automation this task would have required a great deal of programming time and effort; but because of OLE Automation this task is greatly simplified, as only ten lines of code will accomplish the desired task. Although this may not appeal to the casual user, this simplicity is attractive to many large corporations who need customizable applications. These corportations have been the major market that OLE Automation has catered to.

OLE Automation also requires very little programming maintenance over the years, as the object names that are exposed by the original application developer will rarely change; implying that a program written using Word 6 and Excel 4 in 1993 will work with Word 7 and Excel 6 in 1996 just as well.

Problems with Implementing OLE Automation

From the introduction one may have the view that OLE Automation has no disadvantages and is a big step in the world of programming. However, exposing the objects in the original application can be quite a time consuming and inefficient process if done incorrectly, and many software corporations fall into this inefficiency trap because OLE Automation is so new they do not know how to apply it effectively. The purpose of this section is to examine these traps.

In the software design industry it is common practice for a members of a development team to each be assigned separate features of a product. Unfortunately, as a result OLE Automation is usually given as an entire task to one individual. This has several ramifications, all of which combine to give an unsatisfactory implementation of OLE Automation.

The problems start in the design of how OLE Automation will be implemented. Because one person has to design OLE Automation, naturally they determine which features of the application will be exposed and how the user will manipulate them. This can create problems because the Automation team member will be exposing objects that were designed by other people, and thus may end up making certain objects more difficult for a user to access than others.

For instance, if one team member is working of a line utility for an application, they will usually have little or no input as to which line features will be made available or how these features will be made available. Thus the OLE Automation team member may plan to expose the line length and line width; when in fact the two most important line properties to expose are the lines color and number of nodes. As one can see, an error has already appeared in OLE Automation in the high-level design phase.

Besides the aforementioned high-level design error, the low-level implementation of OLE Automation is usually inefficient and hard to maintain. This again stems from the division of labor within the project, as each developer will program their section without OLE Automation in mind and thus make the job of exposing objects that much more difficult. By using object-oriented software design concepts, this is because each individual developer does not use methods that are friendly towards the exposing of objects, and thus these methods must be rewritten by the OLE Automation engineer so that each object can be properly exposed.

For instance, using the line tool example again, if one wants to expose a line object for automating, the easiest and most efficient way to do this would be to call a function actually used by the line tool to draw the line. This way, the method to call already exists in the application, so no extra code needs to be written to expose the line object. However, this scenario is usually impossible to replicate in reality because said function almost never exists in the application; the only functions used by the line developer are functions that help the line tool work, not ones that help OLE Automation work. Usually, the only way that the line object could be exposed is to copy bits and pieces from the line tool code, a method that is both inefficient (because very little object-oriented techniques are being used) and hard to maintain (as every time the line implementation changes, code changes are required in both the line code AND in the OLE Automation code as well).

The possible flaws of OLE Automation are now evident in both its high- level design phase and low-level implementation.

Solutions to these Problems

In the previous section problems with OLE Automation were examined in both high-level and low-level contexts. This section will address these problems, providing solutions that will enable a more efficient implementation of OLE Automation.

There are two solutions available for the high-level OLE Automation problems: plan OLE Automation implementation in advance, and divide up the workload of OLE Automation as to not lump it all on one person.

Planning OLE Automation in advance means that in the early stages of the project, all team members should be educated as to what OLE Automation is and how it works. This education is necessary because many software developers consider implementing OLE Automation a very difficult task when in fact it can be quite simple if planned correctly. After this education the team members should discuss how OLE Automation can be most easily implemented and who on the team is most qualified (or most willing) to coordinate the implementation. Also in this planning stage the team members should decide which OLE Automation objects to expose and how to expose them. This should be done in order to make OLE Automation easier for the end user to use, and to also make all team members aware of how detailed OLE Automation will be.

After the planning stage, the chosen OLE Automation leader should divide up the task of Automation between the various team members. Ideally, the leader should still be responsible for about 80-90 per-cent of the actual implementation; the remaining 10-20 per-cent should be assigned so that some of the more complicated Automation routines could be programmed by the people who designed the objects they are meant to expose (eg. the line guru would program the Automation line object ). Another advantage of this is that the individual programmers will keep in mind the needs of the OLE engineer when designing their own sections.

By now the high-level implementation of OLE should be complete. All that remains is actually writing the code which, as pointed out earlier, is error-prone as well. Besides dividing up the programming tasks (as mentioned before) another solution to inefficient low-level implementation of OLE Automation is to use object-oriented design methodologies to create common functions that are used by both the actual tool to be exposed and by the Automation function that exposes it. For example, if the line tool is being Automated it would be ideal if there was a function in the actual line tool code that does most (if not all) of what the Automation code needs to accomplish. This obviously results in a lot less Automation code, implying a more efficient and maintenance free low-level implementation of OLE Automation.

By using both these high-level and low-level techniques the myth that OLE Automation is hard to design and program should be shattered as a maintainable, efficient, and well planned OLE Automation implementation should result.


Accessible and Valid XHTML 1.0 Strict and CSS

Powered by LifeType - Design by BalearWeb