The LA Fox Developer Newsletter

Converting FoxPro 2.6 to VFP

by Jim Slater

Throughout its life, Foxpro has maintained a tradition of backward compatibility. Not only have all old commands and functions been supported in the new version, but design objects such as screens, reports, menus, and projects created in the old version have been usuable in the newer versions. In most cases the conversion process has been automatic: open up an object with an older format in the new version, and Foxpro immediately converts it to the new format.

Visual Foxpro provides automatic conversion of 2.6 projects, screens, reports, and labels (menus, queries, .DBFs, and .PRGs do not require conversion). Conversion must have been considered important by Microsoft; the help file has over 20 screens on the subject. As usual, the conversion is one way; objects converted to the VFP format can

•no longer be used in 2.6. In the case of projects, reports, and labels, the conversion is fairly minor and the resulting object is indistinguishable from one created from scratch in VFP.

Conversion of 2.3 screens VFP forms is far more complex, less transparent, and many would argue, not entirely successful. Screen conversion presented a huge challenge to VFP’s designers. The VFP Form Designer bears little resemblance to the 2.6 Screen Designer. While all of the 2.6 screen objects and snippets are induded, VFP forms have several additional objects, plus dozens of properties and methods that bear no relation to anything in 2.6 Added to this are the new event model, object orientation and inheritance, data environment, private data session, and cursor buffering. Also, VFP executes .SCX’s directly rather than creating a .SPR program file.

Given all these differences, plus the wide latitude that 2.6 allowed developers as to how they designed screens, it was simply impossible to create a generic converter able to turn 2.6 screens into VFP forms without making significant compromises. For the first time, Foxpro developers need to question the wisdom of converting their old screens rather than redesigning from scratch. The remainder of this article will descnbe the conversion process and discuss the limitations of converted forms.

The options are:

Backuø files - If this box is checked, VFP will create an OLD\ subdirectory in the specified directory, and place in it un-converted backup copies of the 2.6 objects.

Create log file - If checked, VFP will create a text log file with the specified name listing all objects in the project and whether they were converted or left unchanged.

Functional conversion - If selected, VFP will create a fully-functioning form for each screen in the project. It will include all the snippets from the original 2.6 screen. This is the option to use if you want to run your converted application immediately. Visual conversion - If selected, the snippet and procedure code from the 2.6 screens will not be placed in the new VFP form, but instead will be put into a non-compilable .PRG file whose name is specified at the right. This is the option to use if you want to modify the converted form to take advantage of the VFP event model. An application converted this way cannot be run until you make these adjust (Con't, page 5)

Page 4