Remember the days when you could totally control what was on the machines that ran your applications? When you didn't have to worry about interactions with other software or hardware? I had another reminder recently just how gone those days are. Another developer hired me to automate the production of a particularly complex report. It required intricate formatting that was beyond the capabilities of VFP's Report Designer. In fact, even in Word, it was far from easy.

Before beginning, I confirmed with the other developer that the target for this task was VFP 7.0 automating Word 2000. Many hours later, I had the thing working with the sample data I'd been provided. I sent it to my client, indicating it had to be tested with a larger data set.

That began several weeks of working with the client. He couldn't get my code to run consistently. The first time he ran it, all was well, but subsequent runs bombed with an OLE error. I couldn't replicate his error. As we worked our way through the issue, the first thing I learned was that he was running Word XP, not Word 2000.

Patching it up

After a lot of back and forth, we determined that whatever was going on was a timing problem. When he stepped through the test program, it worked fine, but running it at full speed failed. Sure enough, adding a brief WAIT TIMEOUT just before the command that caused the error solved the problem, but that was only a patch. We really needed to know whether this was due to a problem in Word XP, or something else, so the other developer could know what to tell his client, the ultimate user of this application.

I asked around among the Word and Office experts I know and Beth Melton, a Word MVP, came up with the answer. The problem wasn't with Word at all, but with the Office Plug-In component of Norton Anti-Virus (NAV). It slowed things down enough that the automation process was failing. Sure enough, when my client disabled that plug-in, the problem went away.

This leaves us with a larger problem. How do we ensure that the client doesn't run into this problem or a similar one? My client can't control what anti-virus software his client uses. He can certainly tell them that NAV's Office Plug-In will cause problems, but can we be sure that's the only potential problem?

The code that fails is fairly standard automation code. If another product that isn't even part of this process can make that code fail, how can we ensure any code is safe? Code that performs computations within a single product is probably unlikely to run into issues, but any code that talks to the file system or interoperates among multiple applications seems to be vulnerable to this kind of problem.

While we ultimately found a workaround for this problem, I'm interested in hearing if you've faced similar issues and what you did to make your code work. (Send a description to FoxPro@Advisor.com.)

VFP 7.0 Service Pack 1

We're already reaping dividends from the decision to separate VFP from the other Visual Studio products. The first, of course, was that VFP 7.0 shipped last summer, while Visual Studio .NET was released in January 2002. The second tangible bonus is now available: Service Pack 1 for VFP 7.0.

Because Microsoft released hot fixes right away for a few serious problems, the six-month lapse between product and service pack release seems like just about the right timeframe -- long enough to let people find the problems, but fast enough to keep them from being a major headache.

What's in this service pack?

This service pack contains almost entirely bug fixes. There's one minor enhancement: XMLToCursor() has a new flag that lets you add data to an existing cursor.

What's fixed? A variety of bugs, most of them minor, but a few that have been showstoppers for some people. Probably the highest-profile item is a problem that leads VFP itself or a VFP application at runtime to stay on top of other applications.

A number of fatal errors (including some C0000005 bugs) are fixed. VFP 7.0 is stable to begin with, so this service pack makes it perhaps the most stable version of FoxPro ever.

If you're already using VFP 7.0, download and install the service pack right away (http://msdn.Microsoft.com/vfoxpro). If you're one of those cautious folks who likes to wait for Microsoft to iron out any problems, your wait is over. Go ahead and upgrade now, then download the service pack. Note the service pack is available only as a download; it won't be integrated into the packaged product. After you start working with VFP 7.0, you'll wonder what you were waiting for.