ActiveX is the name for programmable elements, formerly known as OLE controls (OCXs) or OLE custom controls.  The ActiveX programming specification is an extension of Microsoft Windows and the Object Linking and Embedding API.

Microsoft first introduced the term ActiveX at the Internet Professional Developers Conference in March of 1996.  ActiveX referred to the conference slogan “Activate the Internet” and was more a call-to-arms than a technology or architecture for developing applications.  In a very short time, it has become Microsoft's answer to the Java technology from Sun Microsystems.  An ActiveX control is roughly equivalent to a Java applet.  The difference is that while ActiveX controls can interface with Microsoft Windows better than Java, they only offer limited cross-platform support.  Currently, ActiveX controls run in Windows 95/98/NT and in Macintosh.

ActiveX controls can be created using a variety of languages or development tools, including C++, Visual Basic, PowerBuilder, or with scripting tools such as VBScript. It is even possible to write ActiveX controls in dBASE language (as shown by François Ghoche using JazzAge), since an ActiveX control is simply an encapsulated Windows executable. An ActiveX written in dBASE will just need the runtime Vdb7run.exe in order to be executed (like many OCX written in Visual Basic will need some DLLs from VB to run).

ActiveX controls are supported by a wide range of applications (referred to as component containers), including Visual dBASE. A few ActiveX controls are even packaged with VdB 7.01: their use are explained on Gary White's Web site.

An ActiveX control, like a built-in control, is thus an object that you place on a form to enable or enhance what you can do with dBASE. For instance, the application, included with this article, will allow to use a scanner from within dBASE.

How to use ActiveX controls

ActiveX controls carry the “.ocx” file name extension.  You don't need to know where they are located on your computer, dBASE will find them in the Window's Registry. And to use them, just drag and drop an ActiveX control onto the form designer.

But first, you must tell dBASE which ActiveX control you want to use.  To do that, you must call the Inspector from the form designer (F11), find the ActiveX object's classID property, and click on the wrench button at the right.

You will get a list of all the ActiveX controls available on your machine.  As an example, we will select ImgEdit.ocx, one of the .ocx in the Imaging for Windows application.  This application was made originally by Wang Laboratories and distributed free with Windows'95 (starting from Win95-OSR2).  Notice that the ClassID and the name of the control are both in red.

Between Win95 and Win98, the imaging application was bought by Kodak who made a newer version, kept the name of the ActiveX (ImgEdit.ocx), but changed its name in Windows' Registry to “Kodak Image Edit Control”.  These changes are not important for us since dBASE is relying only on the ClassID property in the Registry to select the right ActiveX control.  In fact, the ClassID is the equivalent of an alias in the Borland Database Engine.  The result is that two computers can use a dBASE application based upon an ActiveX control located in different folders, bearing different names and yet the application will still work fine.  Below is the .ocx as it is listed under the French version of Windows'98.  Note that the ClassID is identical.  The path is the same (should it be different, it wouldn't matter).

Once you click the OK button, you are doing two things.  First, you make this ActiveX control available, from now on, in your Component palette (note:  more about this in the next section).  Second, you have created an instance of this ActiveX control.  It is now a dBASE object like any other dBASE control, with properties, events and methods.  To access them, from the Property Inspector, click the “i” tool beside the nativeControl property (or select it from the combobox at the top of the Property Inspector - i.e., where form.activex1 is highlighted in the image at the left).

The list of specific ActiveX controls

The Component palette have a special tab for the ActiveX controls permanently available to be used when you want to create or modify a dBASE application.  To add or delete an ActiveX control from that palette, from the Form designer right-click on the form (step one in the image below) and in the context menu, select “Component Palette - Form Designer” (step two).  Right-click anywhere on the Component palette (step three) and in its context menu, select “Set Up ActiveX Components” (not shown here): you will be offered a mover.  In the left listbox, select the ActiveX controls you would like to have permanently in your Component palette and push the top pushbutton (step four).  From now on, they will be available in that palette, under the ActiveX tab.

To use it in your dBASE applications, you just have to drag'n drop this control.  There is some rare exceptions to that rule:  for example the Windows Media Player will not appear under the ActiveX tab of the Component palette whatever method you use to add it to the list of the specific ActiveX controls available.  To create an application based on it, you will have to drag'n drop the generic ActiveX control from the Standard tab of the Component palette and to use the “wrench” method to set its classID, as shown in the “How to use ActiveX controls” section.

At run time, some ActiveX controls are hidden because they are nonvisual controls.  And like the functions in an application, they do their job in the background.  However, they are visible in the Form designer, where they can be selected and have their properties changed.  The application available at the end of this article is based on two ActiveX controls, one of which is a nonvisual control

Five problems with ActiveX controls

1. Some ActiveX controls are not compatible with dBASE.  The best way to know is to drop one of them on a dBASE form and try to access its properties from the Inspector.  Even if they appear, there are many cases where the ActiveX will be useless for dBASE developers because the controls need parts of the Visual Basic environment to do their job (Jørgen Feder, personnal conversation).

 
2. ActiveX controls have to be registered in Windows' Registry.  Therefore, it is not enough to copy an ocx file from one computer to another.  That means that if you plan to use any ActiveX beside those which are part of standard Windows applets, you will have to installed it on each of the computers you will use it.  If it is a shareware ActiveX control, it usually comes with a setup program (otherwise it is useless).

 
3. Further, if you rely (as I did) on a Windows' applet installed on every computer, there is no guarantee that your code will be universal under Windows.  For example, the ImgEdit.ocx comes in different versions.  The version on my Win95 portable have 30 properties, no event and 16 methods.  The upgrade available for Win95 have 44 properties, 19 events and 64 methods (note:  if you are under Win95 and want to use the dBASE Scan Center, please download this upgrade).  The version on my Win98 desktop computer have 50 properties, 28 events and 84 methods.  So you have to rely on the lowest common denominators or make different versions of your application for different operating systems.

 
4. In the help files, the examples of the code needed to make an ActiveX work are usually written in Visual Basic.  But, even if the ActiveX was made with Visual Basic, once dBASE creates an instance of it on a form, it becomes a pure dBASE control.  You will have to translate the examples in the dBASE language.  This translation is quite simple even if you never used VB.  For example in the dBASE Scan Center, the top right  pushbutton is the Stretch to fit button.  It is using the FitTo() method of the ActiveX control.





If we look at the help file for this method, we will get the following information screen.



Lets analyze this screen.  This method applies to the “Image Edit control” which is the
  form.Activex1.nativeObject
under dBASE.
 

The example of syntax given here is “object.FitTo Option[,Repaint]” which means
  form.activex1.nativeObject.FitTo(Option, Repaint)
where Repaint is optional. In the code of the dBASE Scan Center, this became these two lines:
  x = form.activex1.nativeObject
  x.FitTo(0)
where the parameter 0 (zero) is for best fit.
 

5. Another problem with ActiveX controls is the copyright issue.  If you are a valid user of a software and if you use its ActiveX to make a dBASE application for your own personal use, there is no problem.  But if you make money using an ActiveX you didn't create, even if you are a legal user of the software with which this ActiveX came and if all your clients will buy a copy of this software, that doesn't mean that the way you are using this ActiveX control is an authorized use of this software.  Maybe the software company wants all its users to see its slash screen and receive credit for it.  Maybe it wants its user to look once in a while for an upgrade on its Web site:  how could they, now that the “engine” of the software is hidden under the hood of your own application? So it would be prudent to read carefully the software license before building a dBASE application based on an ActiveX control.  The only “safe” ActiveX are the ones sold as such for the purpose of being used in applications.

The dBASE Scan Center is just an example of the use of an ActiveX control under dBASE (here in its Win98 version).  Actually, it uses two ActiveX controls.  The first one (visible as the big rectangle in the center of the form) is used to open bitmap files, to select pixels, to create simple bitmap objects (freehand drawing, straight lines, etc.), to rotate the image and to change its pixel depth¹.  The second ActiveX, not visible, is used to select a TWAIN² scanner (if you have more than one) and to allow you to use it.

Contrary to what I did in my previous articles for the dBulletin,  I won't give you many examples of code used in this application because each ActiveX control uses different names for its properties, events and methods.  So in the large world of ActiveX controls, no code can be universal.

The only example I will give you is the code used in the Form_onOpen event to display the bitmap file inside the first ActiveX control.

  local x
  x = form.activex1.nativeObject
  x.display()

Here the image property and the display() method belongs to the activex.nativeObject.
  x.image := "Powered9.bmp"
This code looks strange and familiar at the same time, as for any native dBASE control you would use for the first time.  The trick here is trial and error.

Conclusion

Like DLLs, ActiveX are commodities offered to programmers to expand the power of their applications.  When something can't be done natively with dBASE and also can't be done through API calls (like zipping a file), ActiveX controls allow you to do it from within dBASE, without having to run a dedicated software.

There is a wide range of ActiveX controls compatible with dBASE offered on the Web. Up to now, there seems to be a limited interest in ActiveX controls probably because dBASE can already do most of the things we need it to do.  Another reason is that you can be reasonably sure of the result you will get from your own dBASE code and from your API calls, but are totally vulnerable when it comes to ActiveX controls:  ActiveX control can be buggy as any piece of code and when they are, there is absolutely nothing you can do beside waiting for a newer version.

Thus said, ActiveX controls are probably underused in the dBASE community and we hope this article will make them friendlier to use.