I got a call from our longest term customer. We have worked together for some 13 years. Normally I like getting a phone call from them. But I dislike the calls that go something like this: “Rick, long time no see…heh, my computer got hit by a virus when the grandson played an Internet game on it over the weekend. My hardware person said the computer is too old and not worth fixing. He is ordering me a new Windows 7 computer, and upgrading Office from Office 97 to 2010. You don’t think there will be any problems with your Visual FoxPro 5 app, do ya?”
This computer is the only computer for the company and is close to 8 years old, and really did need to be replaced. This customer is running a Visual FoxPro 5 app that I developed in 1997 and has run without major issues since then. The app is so reliable I cannot convince the customer to upgrade it to Visual FoxPro 9.
So let me see, how much could go wrong with VFP 5 on Windows 7 64-bit, using Aero? The app uses Excel to import records via a remote view, and automates Word to generate letters and envelopes via VBA in Office 97. Hmmm, a few versions of Office, lots of potential glitches with Aero, and a handful of ActiveX controls and FoxTools.FLL. My response was: “I don’t have any idea the number of things that could go wrong.”
My greatest concern was the 32-bit ODBC drivers for Excel, followed by the VBA automation, and then the User Interface glitches we have seen in newer versions of Visual FoxPro on Aero. I also used a couple ActiveX controls and had no idea how well it would work on Windows 7.
I did immediately think it was my opportunity to update to Visual FoxPro 9, which means no more Visual FoxPro 5 apps to support. {big evil grin}.
I arrived at my customer’s home. He literally runs his business out of his basement. I start up the app and it immediately crashes on “API library is not found.” Easy one, FoxTools.FLL is not loaded with the run-time files. It took me a little bit of time to track down the location of the VFP 5 runtime files, and copy over a copy of FoxTools. Run-times were in the Window’s SystemWOW64 folder instead of the System32 folder. App up and running FTW. I tested out most of the data entry forms and there are no UI glitches. Customer is happy to see the app running.
Celebration lasted about 2 minutes when we tried to import the Excel file. Hardware dude who moved over “everything” forgot to set up the ODBC driver. This is easy to overlook and I had good documentation on setting it up. I dig around and find the 32-bit ODBC Manager and set up the ODBC driver. Import routine works just fine. Another round of premature celebration follows.
Surely something is bound to go wrong, right? I mean, would I even dare write a blog post about a perfect scenario for an upgrade? Probably not. {g}
Off to test the letter generation code. CRASH! It is not what you are thinking if you are thinking the VBA code was not working. It crashed on the silly progress bar update that runs as the letters are generated. It crashed on the progress bar setting the value to zero, as in zero percent. Odd. I futzed with the code and tried a few things and eventually determined the progress bar was unnecessary for the moment. The VBA code actually ran without a single hiccup once I got past the progress bar not making progress. I am curious about the progress bar, but that battle is for another day. It was more important that the letters and envelopes are generating so the business can meet their commitments to their customers.
Oh, and thanks Microsoft for keeping backward compatibility with VBA and the Excel ODBC driver in Office 2010 on Windows 7. Nice job! Kudos to everyone on the Office team for not making my life miserable and showing the customer that his investment in Visual FoxPro and Microsoft Office was a well placed investment.
The only things I wished I had today was the current error handler we use, and time to dig into the progress bar issue. The error handler I wrote back in 1997 feels weak. The one we use today is way more robust. I am speculating that the progress bar only accepts integers and I am passing decimals, or it is looking for the percent.
The moral of this story is to add one more thing to consider the next time a customer calls and wants to upgrade to Windows 7: native Windows ActiveX controls. Silly thing is I avoid most of the Microsoft ActiveX controls these days because of the deployment headaches. Not a single issue I worried about materialized. It was the unexpected problem that consumed most of my time. That, should not be a surprise.