OLE Custom Controls in VFP
Steven M. Black
SBC / UP!
Support for OLE Custom Controls is one reason why Visual Basic developers are so keen about their platform. Visual FoxPro now joins the fray! In the months ahead, Custom Controls should transform the FoxPro third-party market. In this session, we will examine how to use Custom Controls in VFP, look at what the Custom market might bring us, and along the way develop a few working examples.
On the VFP Form Controls toolbar, we find two OLE Control buttons. One is for the OLE Container Control, and the other for the OLE Bound Control. The OLE Container Control is used to hold Custom Controls, while the OLE Bound Control is used to link a form to a General field. In this session we focus primarily on the OLE Container Control.
What is an OLE Custom Control?
The Custom Controls supported by Visual FoxPro are 32-bit Windows DLLs that will usually possess an .OCX file extension. OCXes can contain one or more actual controls. You use custom controls like you would any of the native Visual FoxPro controls.. When you add a Custom Control to VFP, it seamlessly integrates into your development environment.
Custom Controls don't need to be actual controls. They don't even need to be visible. A better name for Custom Controls is Custom Components. When you get down to it, Custom Control DLLs are just windows. Most don't exhibit the usual trappings of windows like visibility, titles, and borders. They are simply Windows programs that are what they are because of the way they plug into the Windows environment. In a perfect world, we could use the same Custom Control in all our applications.
Custom controls currently come in a variety of flavors. VBXes are 16-bit custom controls. FoxPro requires 32-bit OCX Custom Controls. OCXes are not simply VBXes compiled with a 32-bit compiler, nor are OCXes a superset of VBXes. OCX technology is an entirely new standard, and while not very much different from 16-bit VBX technology, it will take a while before VBX vendors extend their product line with 32-bit OCX versions of their VBXes.
Sixteen-bit VBX technology is being phased-out by Microsoft, and future versions of Visual Basic and Access will support 32-bit OCXes. In this respect, FoxPro is leading the way. The downside is, for the moment, that it may take some time before a reasonable selection of 32-bit OCXes is available. Keep your eyes on the FoxPro's trade magazines: as OCXes become widely available, you will see increasing numbers of exciting third party products advertised therein.
The Visual Basic add-on market is rich with a variety of gizmos and tool kits, some selling for several hundred dollars, but most go between $49 and $149. VBXes are ubiquitous, and for the most part, necessary to supplement Visual Basic's native controls.
Visual FoxPro is a little different: it comes with a pretty good Grid and a Pageframe control, which are among the most popular types of Visual Basic VBX controls. As a result, many VFP developers won't have much need for OCXes, or at least their appetite for OCXes will be considerably less than that of VB developers.
Still, once OCXes become available, I expect them to really take off.
Where do Custom Controls come from?
Visual FoxPro will ship with some sample Custom Controls. The Outline Control is used for creating dialogs like those found in the VFP project manager wherein you can expand and collapse hierarchical information displays. The MAPI Custom Control contains a variety of functions to endow VFP applications with electronic mail functionality over Windows NT.
You cannot create OLE Custom Controls in Visual FoxPro, Visual Basic, or Access 2.0. Custom Controls can be created with C++ and, in the case of Microsoft Visual C++, using also the Controls Development Kit. Note that any C, C++, or Pascal compiler that can generate Windows programs can be used to create Custom Controls.
What can we expect in terms of OLE Custom Controls?
Custom controls will arise from the following two motivations:
Not satisfied with the VFP Grid object? A number of third-party grids will be available, as well as list boxes, charts, and a wide variety of other controls. After all, in the short term, how can Microsoft hope to compete with "Grids-R-Us" firms who are focused on creating feature-rich grid objects?
Another example, the MSOUTL32.OCX (Outline Custom Control) that ships with Visual FoxPro has a number of limitations. For example, only one font, one foreground color, and one background color is available for the entire object. Also only one icon is available for any given outline level. Also, events don't fire in quite the way we would like, and we would like more events for finer control. Expect a third-party outline control to address and eliminate most or all of these limitations.
Expect to see the following capabilities, among others, to be supplied by vigorous and innovative third-party developers:
Using OLE Custom Controls in VFP
In this section we'll discuss the basics of integrating Custom Controls in Visual FoxPro.
Registering Custom Controls
OLE Custom Controls live in your WINDOWS\SYSTEM subdirectory. In order to use them, you must first register them with Windows so to make them available in your applications. This process may happen automatically with the shipping version of Visual FoxPro, though this is a manual step is required in the early Beta versions of VFP. In any event, some third-party OCXes will need to be registered manually. Here's how.
First, use the REGSVR32.EXE program supplied with Visual FoxPro to register the OCX. Assuming we want to register MSOUTL32.OCX, issue the following command from the Windows FILE-RUN dialog:
When successful, you will get a dialog that looks like this.
As soon as you register an OCX, the following things happen.
You can now use the new controls just as if they were standard controls, and add them to form in your application. Each Custom Control has its own properties and methods, which you can access through the Properties window.
Adding a Custom Control to a Form
In the Form Designer, click on the OLE icon, then click on the form where you want the control to appear. This will invoke the following dialog, where we can specify the appropriate control. Here we will chose the Outline control:
Which will then place the Outline Custom Control on the form with the top left hand corner placed where you clicked.
Custom Control Properties
As with most things in VFP, when you are over an OLE Control. RIGHTMOUSE invokes a menu of appropriate tasks. This is a good way to invoke the Properties Window. Many custom controls have their own interactive property-setting mechanisms custom property sheets to allow us to interact with them. Here, for example, is the property sheet for the outline control. What we see here is not Visual FoxPro; it comes from the OLE Control itself. Look, no data source properties!
The outliner in VFP has no data binding properties...
...but the outliner in the Access 2 ADT does, albeit without class for now.
Subclassing Custom Controls
OLE controls are not, in and of themselves, naturally object oriented. Standing alone, of the three main conditions for object orientation, only one is satisfied by custom controls: encapsulation. Only when we place Custom Controls in classes, thereby allowing inheritance and polymorphism, do we make them objects. One of the great things about the implementation of Custom Controls in Visual FoxPro is the ability to subclass them. No other product can do that (yet).
As with all VFP controls, you should always subclass your Custom Controls. Why? Unless you have the source code for your controls (and some C++ skills) you cannot modify the PEM's of base classes. If you start from a subclass, you can modify all your objects in one fell swoop. This is handy not only when we tweak the class, but also when we want to implement a new or different control.
Custom Controls in Code
Like everything else, Custom Controls can defined with code. The key difficulty of defining Custom Controls with code is correctly specifying the OleClass property. Here a Microsoft Outline control is specified in code. Note the "MSOutl.Outline" value for the OleClass property. To reckon the OleClass for a given control, open the Registration Editor, double-click on the control, and consult the identifier field, as illustrated in the diagram following the code below.
DEFINE CLASS OLETestForm AS Form
Backcolor = RGB( 192, 192, 192)
Caption = "Sample Coded Outliner"
Height = 25
Width = 100
CloseAble = .F.
ShowTips = .T.
ADD OBJECT btnQuit AS MyQuitButton WITH ;
Left= 1, ;
Top = 0.5
ADD OBJECT oOutline AS MyOutline WITH ;
Top = 5, ;
Left = 10, ;
Height= 15, ;
Width = 80
DEFINE CLASS MyOutline AS Olecontrol
OleClass = "MSOutl.Outline"
*-- Just add something, anything.
THIS.AddItem("Item " + LTRIM(STR(THIS.Listcount)))
DEFINE CLASS MyQuitButton AS CommandButton
StatusBarText="Push to terminate"
ToolTipText= "Release this form"
Width = 15
Height = 2
Visible = .T.
Consult the RegEdit Itentifier to reckon the OLEClass property.
So there you have it, a quick tour of VFP's usage of Custom Controls. Of all the new features in Visual FoxPro, support for OLE Custom Controls ranks among the most flexible and powerful. Soon we should have a good selection of third-party controls to chose from, and this will change the ways we think about, use, and apply FoxPro.