Converting FoxPro 2 program code

The syntax and basic control structures of the FoxPro programming language have not changed. New commands have been added over the years and some have been extended with extra optional parameters but a program that will run in FoxPro 2 is very likely to run in Visual FoxPro with no changes at all. In fact, a program that will run in FoxPlus or in dBaseII is very likely to run in Visual FoxPro.

New commands

One problem you may face is that the new object-oriented commands and extensions have added to the list of reserved words in the FoxPro language. The compiler will tell you whether your old code uses any of these new reserved words. A typical problem is to find that one of the functions you wrote for the the old application has the same name as one of the new commands in the language.

The Code References option on the Tools is very useful when making these sort of changes. It will find every use of a particular word and display a list of the file names, line numbers, and the actual line of code. You can then either open each entry in the editor or perform a global search and replace.

Variable scope

Programs written in Visual FoxPro rely heavily on the new Local scope of variables but the old PRIVATE declaration is still supported. If you do decide to convert declarations from PRIVATE to Local, remember that private variables are visible beyond the routine in which they are declared. Some Fox 2 programmers would rely on the fact that a procedure or function can see the private variables in the calling routine and they would not bother to pass the values across as parameters. This was especially useful when you wanted to print a value from memory in a report. A variable declared as PRIVATE in the calling routine would be visible to the report. One declared as Local will not be visible.

Displaying a messagebox

If the original code uses the MSGBOX() function from the FoxTools library then replace it with the newer MessageBox() function. Both these will display a standard Windows dialog but note that the three main parameters of the function are in a different order now.

The MSGBOX() function was not part of FoxPro for Windows but was supplied in the external FoxTools.fll library. It is one of several commands which have been promoted into the language. Others (such as JustStem() and similar file-handling functions) cause no difficulty because they have kept the same syntax but there is a difference in the sequence of parameters between MSGBOX() and MessageBox():

Both these functions use the same basic set of numeric codes for <type>. A code of 36 is recognised as meaning the question mark icon (32) with "Yes" and "No" buttons (4) so the easiest solution might be to write a simple MsgBox function in VFP which switches the order of parameters and calls MessageBox().

Calling a function

In FoxPro for Windows a call to a function had to have an equals sign, even if the value returned was thrown away or assigned to a dummy variable. Visual FoxPro allows you to call something like the MessageBox() function directly:

Possible Problems

Conversion of a FoxPro 2 program is very much more difficult if it is calling any sort of external component or code library through a low-level DOS interface. Anything relying on direct access to hardware such as communications ports or the use of bespoke printer drivers is unlikely to work without a great deal of effort.

FoxPro 2.6 used generator applications such as GenMenu and GenScrn to generate the programs for menus and screens. There were third-party tools which replaced and extended these generators and the code that they produced took full advantage of some of the more obscure features of the language. If your application relies on these sort of extensions then conversion will again be difficult.

Introduction | Data | Program code | Menus | Reports | Screens | Strategy