Converting FPW 2.6 program code

The syntax and basic control structures of FoxPro have not changed. New commands have been added and some have been extended with optional parameters but a program that will run in FoxPro 2.6 is very likely to run in Visual FoxPro.

The new commands and extensions have added to the list of reserved words in the language. You will have to check whether the old code uses any of these new reserved words. A typical problem is to find that one of the functions in the old application has the same name as one of the new commands in the language.

Programs written in VFP rely 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.xx 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 them across as parameters.

If the original code uses the MSGBOX() function from the FoxTools library then replace it with the newer MessageBox(). Both these will display a standard Windows dialog but note that the parameters 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 the JustStem(), JustExt() family) 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 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 way out might be to write a simple MsgBox function in VFP which switches the order of parameters and calls MessageBox().

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 the MesssageBox() more easily:

Possible Problems

Conversion of a FoxPro 2.6 program is very much more difficult if it is calling any sort of external component or code library. Anything relying on direct access to hardware such as communications ports or the use of bespoke printer drivers is unlikely to work without a lot 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