Using Object Linking and Embedding (OLE) from PowerBuilder - whether in OLE Automation or the use of ActiveX controls - has long been a source of frustration for many PowerBuilder developers.

There are several reasons for this:

• There is a lack of a full understanding of OLE.
• There is little documentation and practical examples of using OLE with PowerBuilder.
• There are some limitations inherent in the method that PowerBuilder implements OLE.

This article is intended to address some of these issues by providing a primer on OLE, providing some practical examples of its use, and demonstrating some methods for addressing the limitations of PowerBuilder's implementation of OLE.

The first thing we need to do is cover some background information, beginning with some definitions of terms and then some explanation of how OLE works.

Definitions
COM (Component Object Model) was Microsoft's response to CORBA (Common Object Request Broker Architecture) and is an umbrella for a number of different implementing technologies such as:

• DCOM: Distributed COM
• COM+: Microsoft's response to Enterprise Java Beans (EJB)
• OLE: Object Linking and Embedding

We're primarily concerned here with the last of those, OLE. OLE is a framework that allows individual applications and controls to be combined into a "compound document" that can interact with the user and with each other. When one application is using OLE to interact with another application, the process is called OLE Automation. If the OLE interaction is between an application and a control, the control is referred to as an OLE Custom Control. Originally, OLE Custom Controls were referred to as OCX controls, but were later renamed to ActiveX controls.

OLE objects implement either an interface called IUnknown or an interface called IDispatch or they may implement both, in which case they are referred to as having a dual interface. OLE objects also provide a type library that contains a definition of the objects that can be accessed, their properties, events, and methods as well as the constants that are used when working with the object. This is somewhat similar to the textual include files used with C, except that a type library is a binary file and uses Visual Basic (VB) specific data types.

If a development tool is capable of utilizing the OLE object's type library, it can perform early binding in which the IUnknown interface is used and all references to objects, properties, methods, events, and constants for the OLE object are validated when the code is compiled. Doing so, however, requires support for the VB data types used by the type library. A number of development tools - including PowerBuilder - don't implement the VB data types. Instead, they utilize late binding through the IDispatch interface, in which all the references to objects, properties, and events for the OLE object are not validated until the code is actually run. This also means that these development tools are unable to directly reference the constants defined in the type library.

There are some advantages to the late binding approach. This is particularly true in the case of OLE Automation, where the end user of the application may have a different version of the target application that the developer designed for. Late binding allows for graceful failure of references to objects, methods, properties or events of the OLE object that don't actually exist at runtime. Such can be the case if the end user has a different version of the target OLE application than the developers used. This is somewhat similar to triggering an event in PowerBuilder using the "dynamic" keyword. The event does not have to exist at script compile time, and if the event does not actually exist when the code is run, a "silent" failure will occur (the application will continue operating unaffected).

This is, however, the greatest source of frustration for PowerBuilder developers trying to use OLE. The script appears to be correct, because PowerBuilder allows the application to compile. However, nothing works correctly at runtime. A late bound call to an object method can fail at runtime because:

• The object that it exists on has not been instantiated yet during runtime (e.g., referring to properties of an Outlook message object before the message has been created).
• The object referred to does exist, but the method called actually belongs to a different object (e.g., calling a method that belongs to the Word Document object, but using the Documents object).
• The name of the method is spelled incorrectly.
• The number and/or data types of the arguments passed to the method do not match any valid combination for that method.

When a runtime error does occur, the error message provided is generally not helpful in determining which of these issues (or others) caused the error. And unless they are using a third-party utility that can use the OLE object's type library, PowerBuilder developers can't simply browse through the OLE object to validate the call the way they can for PowerBuilder objects.

One other type of OLE object you may run into is called an ActiveX Designer (for example, Data Dynamic's Active Reports). ActiveX Designers may look like other OLE Custom Controls, but they are actually add-ins for Visual Basic that are custom designed to interact with the Visual Basic IDE. As a result, they won't operate correctly within PowerBuilder. (see Figure 1)

OLE Custom Controls
We will cover OLE Custom Controls first because they are a bit simpler to work with. One reason is that although OLE Custom Control methods and properties are late bound and as a result are not directly viewable within the IDE, their events are exposed within PowerBuilder. Therefore you can at least browse the events of the control using the Object Browser and code those events within the User Object painter. (see Figure 2)

In addition, OLE Custom Controls have the OLE Control Properties and OLE Control Help buttons in the Properties view within the User Object painter.

The example being shown here is for the TX Text Control object from The Imaging Source Europe GmbH. Because it's actually a set of four controls, I've created a Custom Visible user object that acts as a container for the set. (see Figure 3)

I've then added functions to the custom visible user control for the various operations that I want to use. Those functions, in turn, interact with the OLE Custom Controls. By doing this, the issue of dealing with late binding is contained within the custom visible user control.