Mastering PowerBuilder

OCX Control Architecture

As extensions to the existing OLE 2.0 specification, the OCX control architecture is built on proven technology and an industry-wide standard. Both 16- and 32-bit components can be developed using the same OCX control source code (simply recompiling) under Windows 3.1, the Windows NT operating system. The new architecture also opens up the possibility of OCX controls being available in the future on additional operating systems such as the Macintosh or UNIX.

An OLE Control (OLE 2.0 control in the window) is an OLE InProc object (an OLE object that loads into the address space of its container) with some extended functionality. All OLE 2.0-compliant containers (for example, PowerBuilder) can already hold OLE Controls. The controls (OLE 2.0 Control in the window), however, can only get events in containers that support OLE Control events.

This doesn't matter for some controls. Consider the case of a calendar control that lets you click to change the month. If you only need to display the month, you could insert the control and click to the month you want.

The purpose of most controls, however, is to send event notifications to their parent. Most existing OLE containers, such as those generated by AppWizard in Visual C++, don't know how to handle these event notifications. For instance, if you drop an OLE Control push button into a container that doesn't support OLE Controls, you can push the button as much as you want, but the container doesn't know how to respond.

In a container that supports OLE Controls, this button control would send events to the container, which would then respond appropriately. For example, you could insert an OLE graph control into PowerBuilder, and the graph control would display the temperature. If the temperature were higher than the record temperature, the control would fire an event to PowerBuilder. The PowerBuilder application would handle this event. This function would then display "Record temperature reached today".

An OCX control is an embeddable object with in-place activation capabilities. Every OCX custom control has three sets of attributes:

• Properties: Named characteristics or values of the control such as color, text, number, font, and so forth.
• Events: Actions triggered by the control in response to some other external actions on the control, such as clicking a mouse button or pressing a key.
• Methods: A function implemented in the control that allows external code to manipulate its appearance, behavior, or properties. For example, an edit or other text-oriented control would support methods to allow the control container to retrieve or modify the current text, perhaps performing operations such as copy and paste.

A VBX custom control communicates with its container application based directly on Windows message processing. Visual Basic prefixes a control handle (HCTL) onto a standard Windows message and passes the message on to the custom control. The custom control can then process the message and send it back to Visual Basic and Windows for default procedure handling.

In contrast, OCX control communication is based on the standard OLE 2.0 Automation Interfaces for OLE objects. An OLE 2.0 interface is essentially a pointer to a table of functions, any of which can then be executed. The OCX control architecture also adds support for events, a standard way for the control to invoke a call back in its container.

Home	Previous Lesson: Component Based Software Next Lesson: Inserting an OCX Control