The LA Fox Developer Newsletter

Converting (Con't from page 4)

ments.

How Functional Conversion Works

In order to duplicate how a 2.6 screen works, VFP’s

designers included the concept of “2.6 READ com-

patibility mode” in VFP forms. This is not a single

setting, but rather is implemented through the use of

various properties, events, and objects. A form

created in this manner is unlike anything you would

(hopefully!) ever consider creating yourself.

Some of the distinctive features of compatibility

mode include:

(1) FormSet - Every 2.6 screen set is converted into

a VFP FormSet, even if the original contained only a

single screen. Each screen in the original screen set

will be a separate form within this FormSet.

(2) FormSet Window Type - Normal VFP form and

FormSets have a WindowType of 0-modeless or 1-

modal. FormSets converted from 2.6 have a window

type of 2-Read or 3-Read modal. This changes the

behavior of the form so that (a) execution pauses at

the Show method to mimic a READ command; (b)

parameters are passed to the Load method rather

than the Init method; and (c) variables created in the

Load. m3thoci are visible to the other

than being local to theLoa&rnethod. (Nbté that

Window Type 2 and 3 cannot be selected for a new

form in the Form Designer). -

(3) Read snippets - VFP ForrhSets include several

properties and events that correspond to clauses of

the 2.8 READ command: ReadCycle, ReadLock,

ReadMouse, ReadSave, ReadTimeout,

ReadActivate, ReadDeactivate, ReadShow,

Read Valid, and ReadWhen. The converter auto-

matically transfers your 2.6 READ snippets and

directives to these locations. In addition, #Section 1

of the Setup code is placed in the Load method of

the FormSet, and #Section 2 of the Setup code is

placed in the Load method of the first form.

(4) PaaeFrame - Each Form within the FormSet

contains a PageFrame with no tabs. All the objects

from the screen are placed on a page in this

PageFrame.

(5) Data environment - If the original 2.6 screen had

an Environment saved with it, a Data Environment is

created in the VFP form, along with code to save

and restore the position in each table.

(6) . SPR program file - For each 2.6 screen, a .SPR

program file is created, in addition to the the match-

ing VFP form. This may seem strange, since VFP

How Visual Conversion Works

The Visual conversion option does not implement

2.6 READ Compatibility mode, on the assumption

that you want to make your own decisions on how to

implement 2.6 snippets and procedures in the new

form. It handles the 6 steps above as follows:

(I) FormSet - A FormSet is still created, with each

screen in the 2.6 screen set appearing as a Jorm

within it However, no Method code is placed in the

FormSet As a result, if your 2.6 screen set jcon-

tamed only a single screen, you can safely delte

the FormSet using the “Remove Form Set menu

option on the Form Designer.

(2) EQrnjSet Window Tyne - This is 0 or I, depend-

ing on whether yur original form was modal.

(3) Read snippets - All Snippet code from your

original screen is placed in a separate non-

compilable .PRG file that you designate at the start

of conversion. The code has comments indicating

where it would go if you had done a Functional.

conversion (e.g., “PROCEDURE ReadValid’).

(4) PaaeFrame - No PageFrames are placed in the

form.

(5) Data Environment - If the original 2.6 screen had

an Environment saved with it, a Data Environment is

created, and code to save and restore the position in

each table will be placed in the non-compilable . PRG

file.

(6) . SPR oroaram file A separate .SPR will not be-

created, so you must remove any lines in the appli-

cation that called the .SPR, and substitute the

appropriate “DO FORM’ command. Code that would

have been in the .SPR if you had done a Functional

conversion is placed in the non-compilable .PRG file.

Conversion Limitations

During the beta program, many conversion bugs

were discovered and corrected. Given the wide

(Con't, page 6)

Page 5