Including ActiveX ControlsIn Your Application

Including ActiveX ControlsIn Your Application

As hard as it's going to be to believe, there will be times when you just can't get Visual FoxPro to do something on its own. Instead of just throwing up your hands and disappointing your customer, it's time to extend Visual FoxPro's native capabilities through the use of ActiveX controls. In this chapter, I'll explain what they are, show you where to find them, and demonstrate how to use them in an application.

Visual FoxPro joined the big scary world of components back in 1994 when ActiveX control (called "OLE control" back then) integration was added to the product for version 3.0. This is the ability for discrete applications to communicate with each other, and is provided though two mechanisms. One is ActiveX Automation, where one full-blown application can control or be controlled by another. This topic is the subject of an entire book, Microsoft Office Automation with Visual FoxPro, by Tamar E. Granor and Della Martin.

The other mechanism is to extend an application through third-party objects. These objects, or controls, can be placed in any application that supports the ActiveX specification. For instance, a graphics control written to the ActiveX specification could be placed in a Visual FoxPro form, a Visual Basic form, or any other design tool that is compatible with ActiveX.

ActiveX controls can add tremendous flair to your application. Indeed, you could build a Visual FoxPro application that consisted of little more than a wrapper around a robust and highly specialized control. For example, you could use VFP to act as a front end to a mapping ActiveX control, relying on VFP's data handling to grab information from the user and select values from a table. Then you'd send those values to the ActiveX control where all of the heavy duty lifting would be performed, and an end result would be returned by the control to VFP for presentation to the user.

What is an ActiveX control?

An ActiveX control is a file (or files) that provides additional functionality to a Windows application. It usually takes the form of an .OCX or .DLL along with, optionally, other associated files. These files are usually located in the WINDOWSSYSTEM directory on Windows 95/98, or the WINNTSYSTEM32 directory on Windows NT.

You might also see a file with the same stem and a .DEP extension. This is a dependency file, which is simply a text file that contains information about the run-time requirements of an ActiveX control. For example, a dependency file might list which files are needed, how they are to be registered with Windows, and where they should be installed.

You might also find a file with the same stem and an .SRG extension. This is a license file that points to a key in the registry. You shouldn't have to mess with it at all.

Once you acquire an ActiveX control, you'll install it on your system much like you would any other Windows program. Then you'll typically have to perform some sort of "registration" process so that your development tool, such as Visual FoxPro, knows that it's there. Once you've performed both of these steps, the ActiveX control will be available much like all other controls in your development environment.

ActiveX controls typically have a visual component because they are often intended to supplant or replace existing functionality. If you've worked with VFP grids, you can quickly come up with a list of enhancements you'd like to see-for example, intelligent headers, more variety in the control in each cell, intelligent resizing of column widths and row heights, the ability to highlight the current row and/or cell in a variety of ways, automatic parent and child displays in one grid, and so on. You can get an ActiveX grid control that has more functionality than the native VFP grid.

However, ActiveX controls don't always have to have a visual display. You can get an ActiveX control that performs communication tasks, either through a serial port or through the network. This control may or may not have a visual component-and even if it does, you might choose not to use it.

Where-and how-do I get them?

ActiveX components can be found everywhere; indeed, that's become a problem. It seems that nearly every Windows product now comes with a handful of ActiveX controls.

In the box

Microsoft Windows comes with several controls, and each of the visual tools in Visual Studio comes with its own set as well. If you have Visual Studio instead of just VFP, you should install Visual Basic if for no other reason than to install all of the controls that come with it.

I can't keep track of which controls come with each tool, but the Visual Studio online help lists which controls come with each product. Tables 23.1 and 23.2 list the .OCX files that are installed with VFP and VB, respectively.

Okay, you're probably thinking, "Some of these sound cool, but where do I go for more information? How do I find them? How do I know if they're going to work with Visual FoxPro? How can I make sure my car doesn't get dinged in the shopping center parking lot when I go shopping next weekend?"

First of all, these are all found in the Windows SYSTEM or SYSTEM32 directory. You can also do a search on ".OCX" in Windows Explorer if you are looking for a specific control.

The VFP table nicely lists the help file for each ActiveX control, whereas you're pretty much on your own with VB. There isn't necessarily a 1-to-1 relationship between the name of an .OCX and its help file, because a single help file might cover multiple ActiveX controls.

You can find these tables in the MSDN online help under the topics "ActiveX Controls Overview" (for Visual FoxPro) and "ActiveX Controls File Names" (for Visual Basic).

As far as knowing whether a particular control is going to work with VFP, you're pretty much on your own. You should have a reasonable expectation that they will, but you can also bet on a few idiosyncrasies as well. The Microsoft controls are reasonably well-behaved-once you wander further afield, the possibility that you'll run into anomalous behavior increases.

Table 23.1. ActiveX controls installed with Visual FoxPro 6.0.

Table 23.2. ActiveX controls installed with Visual Basic 6.0.

More? You want more?

Of course, like other gadgets, you can never have too many ActiveX controls. (Well, actually, you can, depending on the type of hardware and other system resources available on your machine-but that's a different matter.) Where should you go to find them?

The first place to start, as far as I'm concerned, is a place called www.vbextras.com. Run by Mike Schinkel, these folks have been in the biz for years and years, and they put out the nicest little (well, okay, 120 pages isn't exactly little) catalog dedicated to ActiveX controls and ancillary products. It's the rare individual who can leaf through the entire catalog without turning down the corner on at least three or four pages: "Oh, cool! I've gotta have that one! I don't know what I'm going to do with it, but I've gotta have it." The next place to look is www.active-x.com. It's dedicated solely to ActiveX controls and will get you deep into the mix.

From these two sites, you'll be able to find links and search engines to just about anything you might want.

Once you find an ActiveX control of interest, you'll want to determine whether the ActiveX control will work with Visual FoxPro. There are four possible situations. The first is that the vendor has already tested and determined that it will. Controls from DBI Technology (www.dbi-tech.com) and Microsoft fall into this category. The second is that the vendor will claim that it does, but they haven't actively tested it. The third category is that the vendor will indicate that they know positively that the control will not work in VFP. The fourth is the catchall of "We don't know-why don't you try it out for us?"

Lest you think that I'm being negative about this situation, or just harping on it too much, let me reassure you that I don't mean to be-I'm just dealing with reality. The fact is that no ActiveX control is going to work with every development tool. The differences in the way each tool hosts an ActiveX control are large enough that the only ActiveX control that will work everywhere is a control that does nothing. And because the VB market is the largest, that's where most vendors concentrate their efforts. This is not to say that controls written specifically for the VB marketplace won't work elsewhere; it just pays to be cautious. Treat each new ActiveX control as Research and Development, not as a well-engineered, highly tested "gimme."

Installing ActiveX controls in Windows

Once you've found a third-party ActiveX control of interest, you'll either have it shipped to you via snail mail, or (more likely) just download it from the Web. In either case, you'll eventually have some sort of installation package. You might have to execute or unzip the file you get from the vendor into a temporary directory to end up with an installation executable, along with, perhaps, a help file, a readme, and other stuff.

First back up the installation file (or files). As I mentioned in Chapter 16, I have a directory on my server called "Zip Archives" in which I store all of the tools I've downloaded or otherwise don't have physical media for anymore.

Next, run the installation routine. This should perform the following tasks: (1) copy the OCX (and any other related files) to the appropriate directory, such as the Windows SYSTEM or SYSTEM32 directory, (2) create a directory for the ActiveX control that includes documentation and samples, and (3) create a Windows Registry entry for the control.

This Registry entry is pretty important, because all Windows development tools will look for controls that are registered (with Windows) in order to know about them.

Manually installing ActiveX controls in Windows

It is possible that the installation won't automatically register the control. If this happens, you can run into several situations that can be rather baffling.

The first is when you look for your brand new ActiveX control in your development environment, and you can't find it anywhere in the list of controls. If it's not in the list, it's not registered.

The second situation can occur when the control is initially registered, but then something on your machine changes, and the registration is removed. However, the control may still show up in the list of controls in your development environment for any number of goofball reasons. When you try to actually use the control in your development environment, the operation fails.

The third situation is when you try to run the application that contains the ActiveX control. Typically what happens here is that the installation routine fails to register the control automatically, and you click on through to finish the install, receiving one of those helpful "Installation failed" error messages. You might still attempt to run the application, the form will load partway, and then you'll get a message along the lines of "Error instantiating control. Record 26 of <name of VCX>." If you're not used to this, you'll end up opening the .VCX manually as a table, only to find out that Record 26 is the pointer to the ActiveX control on the form.

You might also encounter situations where you'll have to manually register it yourself. For example, suppose you're debugging or testing new versions of the control. It's pretty common for the vendor, instead of creating a whole new installation routine, to just send you a copy of the new .OCX and expect you to register the control yourself.

In any of these cases, you're going to want to (or, at least, need to) manually register the control with Windows. Here's how:

                        1. First, you'll need to know the file name of the ActiveX control. Hopefully you know this-either from the list of controls I provided earlier in this chapter, or from examining the installation package of the ActiveX control. You could even do a scan

                        of the Windows SYSTEM or SYSTEM32 directory before and after you did the automatic installation of the ActiveX control.

2.                   2. Put a copy of the control (along with any related .DEP or other files) in the SYSTEM or SYSTEM32 directory. Unfortunately, I can't help you much more in this step- you'll have to read the vendor's documentation (yeah, ha!) or talk to them to make sure you know all of the files needed.

3.                   3. Run the "Reg Server" program to tell Windows that a new ActiveX sheriff's in town. This program, located in the SYSTEM or SYSTEM32 directory, will actually create the appropriate entries in the Windows Registry so that the ActiveX control can be found by other applications and development tools. The syntax of the command, for a control named MYCOOL.OCX, is

REGSVR32 C:WINNTSYSTEM32MYCOOL.OCX

When the Reg Server program is finished, you'll get a dialog indicating success or failure. You can include a "/S" switch to run in "silent" mode-this way you won't get a dialog.

You can run this command from a Command Prompt (that's the 32-bit Windows version of what old-timers call a DOS box). Select Start, Programs, Command Prompt and you'll get a window with the Command Prompt interface. Ah, yes, the good old days. See Figure 23.1.

You can also use the Run menu option from the Start menu. See Figure 23.2.

There are all sorts of things that can go wrong here, and each of these problems is pretty annoying for a developer new to ActiveX, so let me discuss them.

First of all, Windows should know where REGSVR32 is located, so you shouldn't have to type a fully qualified path for the program. Nonetheless, if you've got an unusual configuration (that's French for "screwed up"), REGSVR32 might be installed where Windows can't find it, and you might have to include the full path.

Second, while Windows should know where the .OCX file is, assuming it's in the SYSTEM or SYSTEM32 directory, it might get confused if there are multiple copies of the .OCX file laying around. This can happen particularly if you are running REGSVR32 from a directory that contains a second copy of the .OCX. My advice: Use the fully qualified path name for the .OCX.

Third, you need to include the extension. I've been bitten many a time trying to register a component (particularly an .EXE component) without including the .EXE extension.

If you continue to have troubles with manually registering an ActiveX control, follow these steps (yes, every one of them):

1.                   1. Reboot your machine.

2.                   2. Uninstall (or unregister) the ActiveX control from your development tool.

3.                   3. Unregister the control using the following command:

REGSVR32 C:WINNTSYSTEM32MYCOOL.OCX /U

1.                   4. Delete the ActiveX control from the SYSTEM or SYSTEM32 directory.

2.                   5. Search the Windows Registry for any traces of the ActiveX control. Using the Start, Run menu option, run RegEdit. Then select the Edit, Find menu command inside the Registry Editor dialog. Remove those traces if found.

3.                   6. Reboot your machine.

4.                   7. Reinstall the ActiveX control by copying it to the SYSTEM or SYSTEM32 directory and then registering it with Windows again.

If these steps don't work, you might have a corrupt version of the control.

How do I put them into my development environment?

In the previous sections, I've referred to "registering the control with your development environment." You actually don't always have to do this. It depends on which mechanism you want to use when adding ActiveX controls to a form. Yes, just like everything else, there's more than one way to skin a Fox.

The first mechanism involves dropping ActiveX controls onto a form from the ActiveX Controls toolbar, while the second involves dropping a standard VFP ActiveX Control base class (or your own subclass, of course) onto a form from the Form Controls toolbar and then selecting which ActiveX control is to be associated with that class. You don't need to do anything special if you choose the second mechanism, but you do for the first.

To select ActiveX controls that will be displayed on the ActiveX controls toolbar, open the Tools, Options dialog and select the Controls tab, as shown in Figure 23.3. You can display a list of visual class libraries or a list of ActiveX controls by making the appropriate choice in the option button group in the upper left corner of the tab. One slight annoyance is that the description in the list box control doesn't display completely in the list box-in Visual Basic, you can also scroll the list box to the left and right. You can see the full name of the highlighted ActiveX control below the list box, but that's small consolation. Given the responsiveness of the Fox team, I'll bet we see this fixed in a future version of Visual FoxPro.

This is important because some controls have two versions, and you can't always tell which one you're selecting. In Figure 23.3, the highlighted control is the Microsoft UpDown Control, version 5.0, while in Figure 23.4, version 6.0 is highlighted.

On my system, I've got 191 ActiveX controls registered with Windows. Obviously, you wouldn't want all 191 on your ActiveX controls toolbar-so just select the controls you want to see by checking the check box to the left of the name in the Selected list box, as I did in Figure

23.4.

If the control you want to select isn't in the list, it might be on your machine but not registered with Windows yet. You don't have to leave Visual FoxPro to register the control-if you click the Add button on this tab, you'll be able to point to an .OCX file. Doing so will automatically register the control with Windows and add it to the list box at the same time.

Once you've selected the controls you want, close the dialog, selecting Set As Default if desired. Next, open the Form Controls toolbar, click the View Classes button in the toolbar (the one with the books and the small arrow in the lower right corner), and select the ActiveX controls menu option as shown in Figure 23.5.

Once you select the ActiveX controls menu option, the Form Controls toolbar will change to display just the selected ActiveX controls as shown in Figure 23.6.

How do I use them in an application?

As I mentioned earlier, there are two ways to drop an ActiveX control on a form. Having seen how to populate the ActiveX Controls Form Controls toolbar in the previous section, it's probably pretty obvious how to proceed. You create a form and pop the toolbar's ActiveX control on the form.

While this method is easy to use, it involves more setup. The second mechanism is the opposite-there's no setup required, but each time you drop a control on a form, you have to go through more steps.

First, you'll drop an ActiveX Control on the form in question. The ActiveX Control is found in the Standard Form Controls toolbar, as shown in Figure 23.7.

Once you drop it on a form, you'll get an Insert Object dialog as shown in Figure 23.8.

You'll select the ActiveX control you want in the Control Type dialog, and then click OK. The end result will be the same as if you dropped the ActiveX control onto the form from the ActiveX Controls Form Controls toolbar. See Figure 23.9.

You can actually go a bit further, and create subclasses of the ActiveX controls you want to use, and then place those subclasses in their own class library, which means they'll all be together on their own toolbar. If you make extensive use of ActiveX controls, this might make a lot of sense so that you can keep groups of commonly used ActiveX controls together on the same toolbar.

There are other benefits to subclassing your ActiveX controls. For example, you can add your own standard properties and methods to your class definition, and then every time you create an instance of the control, it will automatically include your additions. You can also create an easier to use interface than that which is exposed by the ActiveX control itself. My tech editor has subclassed the CommonDialogs control and added properties that are easier to set than adding a bunch of numbers together and putting them in the Flags property. You could even add extra functionality.

Once you've got the ActiveX control on the form, there's one more step involved- actually interfacing the control and the rest of your form. How that works depends completely on the control you're using. You'll need to refer to the help file for specifics. Hopefully you'll have sample code-even possibly in Visual FoxPro, but more likely in Visual Basic-so you can follow along in someone else's footsteps.

How do I ship them with an application?

So it's been awhile since the previous section. You've gotten the controls to interface with the rest of the form, you've had a few glitches, or maybe a lot, but you're finally done. The miracle has occurred, and you're ready to ship. What do you now?

It seems pretty logical that because Windows is all integrated, you'd be able to create a build directory containing your executable and a few data files, and then run the Setup Wizard to create a set of installation files. The Setup Wizard ought to be smart enough to find any ActiveX controls in your project and include them with your application's installation files.

Prior to version 6.0, this wasn't the case. You had to copy all of the necessary files associated with your ActiveX control to the directory from which you were going to build your installation files, and then specify which files were ActiveX controls (and some other stuff) during the setup routine.

With VFP 6.0, however, the Setup Wizard will take care of all of this for you. All you have to do is make sure that the appropriate controls are installed properly on your machine. The Setup Wizard will then do everything else. See a complete example in Chapter 26, "Distributing Your Applications with the VFP Setup Wizard."

What if it doesn't work?

Visual Basic programmers have had it very, very good in one respect of development-their tool was designed and built with the assumption that developers would not be relying on native VB, but instead would be extending VB through the use of third-party controls. As a result, many of the most innovative interfaces you see in the Windows world are created with VB.

Visual FoxPro, as does Visual Basic, comes with a set of standard controls-command buttons, option groups, check boxes, list boxes, spinners, and so on. However, Visual FoxPro developers are used to relying on this group of controls, and thus haven't generated as much market demand for additional controls.

The upshot of this situation is that most ActiveX controls are designed and built with Visual Basic developers in mind. Thus the developers of those ActiveX controls don't always consider the Visual FoxPro market, and if they do, they often just give us a passing nod. It has historically been somewhat of a crapshoot whether a specific control will work-or work well-with Visual FoxPro.

If you run into a specific control that seems to be misbehaving, contact the manufacturer. Explain what you're trying to do, and offer to work with them. It takes a lot more time, to be sure, but (at least in my limited experience) vendors are often willing to do something to resolve the problem if they have someone to work with. Many ActiveX control vendors simply don't know anything about VFP, and thus they're limited in terms of what they can test in the first place.

DLL hell

ActiveX controls, for all the benefits they bring, suffer from one serious architectural flaw that Microsoft has been wrestling with for quite a while. As I've said, all ActiveX controls should be in the Windows SYSTEM or SYSTEM32 directory. (Once in awhile, some misbehaving application places its .OCXs elsewhere.) But the idea is by keeping all of the components in a single location, many applications will be able to leverage the same files.

Yes, that's right-instead of having 19 spellcheckers and four zip-code-lookup programs and a dozen pop-up calendar controls scattered all over a user's computer, the ActiveX architecture would allow all 19 programs requiring a spellchecker to use the single copy in SYSTEM or SYSTEM32. And those dozen applications that used a calendar control would all reference the same .OCX as well. This cuts down on the clutter and the wasteful duplication that was starting to occur.

Even better, of course, was the idea of reusable components-you didn't have to write your own zip-code-lookup object; you could simply reuse one that was already built, tested, and installed. Pretty soon, the theory went, all applications would be simply assemblies of mounds and mounds of components. What a sweet deal!

Of course, reality bites.

What has happened is a nightmare of incompatible versions stomping on each other and not working with specific versions of other controls. Here are a couple of examples.

You've built an app using a TCP/IP ActiveX control. You install it on a user's machine, and it's running fine. One day, your user calls you up complaining that it doesn't work anymore. "What changed?" "Nothing," they say. Well, one thing did change-someone else installed a new version of another application that installed an old version of that TCP/IP control used by your app. Big surprise-your app can't use the old version because it requires access to functions that weren't in the old version. So your app is broken, and the user thinks it's your fault.

But it can get worse. Suppose you've built an app using a graphics ActiveX control. Naturally, your app is running fine until the user decides to update their copy of another application. This time, however, the upgrade installs a newer version of the same graphics ActiveX control. And, of course, it's not compatible with your application because it's been changed, just ever so slightly-a method was renamed, or a property's value changed from numeric to character. And again, your application is broken, and the user blames you.

What's the resolution to this situation? There really isn't any. Microsoft is well aware of the situation, and claims to be devoting significant resources to a solution. However, that doesn't help you or me now as we're trying to ship applications.

Many people have developed workarounds. One is a tool used throughout the VB world called Version Stamper (www.desaware.com) that can help to a degree. But the bottom line is that this is a serious problem that, fortunately or unfortunately, most Visual FoxPro developers aren't exposed to often. It is a significant problem for the rest of the Windows world, however, and you need to be aware of it when you start using ActiveX controls.