The LA Fox Developer Newsletter

Converting FoxPro 2.6 to VFP

by Jim Slater

Throughout its life, Foxpro has maintained a tradi-

tion 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 con-

verts 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 conver-

sion). 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 de-

signed 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