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
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
The example of syntax given here
Option[,Repaint]” which means
where Repaint is optional. In the code of the dBASE Scan Center, this became these two lines:
x = form.activex1.nativeObject
where the parameter 0 (zero) is for best fit.
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 depth1. The second ActiveX, not visible, is used to select a TWAIN2 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.
x = form.activex1.nativeObject
Here the image
property and the display()
method belongs to the activex.nativeObject. 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.
2- TWAIN. When the
representatives of the major makers of flatbed scanners had adopted a common
protocol for scanner, these young men in sneakers and T-shirts couldn't
decide on a name for the universal standard they agreed to. For a
joke, they voted for the initials TWAIN (for Technology Without An Intelligent
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.
1- A pixel depth of 1 means that the pixel has two possible values: black or white. A pixel with a pixel depth of 8 has 2 8 (or 256) possible values and a pixel with a pixel depth of 24 has a 2 24 (or roughly 16 millions) possible values.
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.
2- TWAIN. When the representatives of the major makers of flatbed scanners had adopted a common protocol for scanner, these young men in sneakers and T-shirts couldn't decide on a name for the universal standard they agreed to. For a joke, they voted for the initials TWAIN (for Technology Without An Intelligent Name).
(it's a 78Kb zipped executable file)
(it's a 151Kb zipped executable file)