The LA Fox Developer Newsletter

August 1995

Converting (Con't from page 5)

variety of approaches to screen design taken by 2.6

developers, it is likely that other glitches will be

discovered as VFP comes into general use. A few of

the known limitations in the released version include:

(1) Base classes used - All objects in converted

forms use the Foxpro base classes rather than using

subclasses. This means that there is no way to

change the default behavior or appearance of con-

verted forms and their objects without individually

modifying each one.

(2) GENSCRNX and other add-ons - Many develop-

ers rely heavily on GENSCRNX and its derivatives

such as 3D, INBROWSE, etc. These all work by

modifying the .SPR program files generated in 2.6.

Since VFP does not generate a .SPR for its forms,

these add-ons do not work in converted screens.

(The .SPR described in #6 above only serves to call

the form, so it is not useful to GENSCRNX). In many

cases the omission of this code will make converted

forms non-functional. Although there was once

promise of a GENSCRNX conversion program from

Flash, this no longer appears to be in the works.

(3) Generic methods - Many 2.6 developers included

a library of generic “method” code in their 2.6 appli-

cations for navigation and other purposes, such as

NEXTREC() and TOPREC() fus;cnons. If a screen

needed its own custom version of one of these

functions, that code was placed in the Cleanup

section of the screen, and took precedence over the

generic version due to FPWs calling hierarchy. In

converted forms, the calling sequence does not

seem to work the same way; as a result the generic

routines may be called rather than the specific ones.

(4) . FLL incompatibility - All 2.6 .FLL’s must be

recompiled to work in VFP. If your application uses a

.FLL that is not available in a VFP format, you must

determine how to work around it. (Foxtools and

JKEY are available in VFP versions).

(5) Activating browses and multiple windows in form

sets - Many tricks have been employed by develop-

ers to integrate browses with screens, and to ma-

nipulate between multiple windows in a screen set

Due to inherent differences between VFP and FPW-

2.6, some of these solutions will function improperly

or not at all in converted forms.

To Convert or Not To Convert

In the case of projects, labels, reports, and menus,

there is little reason not to convert from your 2.6

versions. The converted objects will be completely

compatioie witn vri’, so wny reinvent the wheel? In

the case of screens, the answer is not so straightfor-

ward. You could choose Visual conversion, Which

would at least give you a form template to work from

to create a “VFP-Iike” form. However, your con-

verted form will use only VFP base classes; most

experts recommend that that you create your forms

and objects from subclasses rather than from base

classes. If, on the other hand, you choose Func-

tional conversion, you will have at best a ‘kludged’

form that bears little resemblance to what you

should be creating in VFP. While this will allow you

to get your app running in VFP quickly, bringing

these converted screens up to VFP standards later

will be a major effort. (The Help file has two full

screens of steps needed to turn a 2.6 READ-com-

patible form into a normal VFP form).

The real question to be considered is why you are

converting the application in the first place. If you

intend to run the conversion and leave it at that, all

you will have is an application that takes m4

resources and runs slower than it did under p.6. If

instead you want to take advantage of the elent

model, database container, cursor buffering, and

other wonderful new features of VFP, you will first

need to rethink your entre aporoath to how yOu-

design forms and how you handle data. Then, you

will need create a set of base classes and builders

to implement your new approach. Once you have

accomplished this, designing a new form from

scratch will be a snap, and you will probably want to

abandon those now-embarassing 2.6 forms anyway!

(Ed. Note: Jim Slater is Vice President of the Rocky

Mountain Fox User Group in Denver, Colorado. He

has been developing database applications in

dBase, Fox, FoxBase, and FoxPro for 11 years. He

can be reached on CompuServe at 76367,1 735J

John Hart, member, for temporaflly solving our

“Projection Blues”. He has very graciously con-

sented to Iethng us use one of the “direct” projectors

from his office for our meetings. This device can be

connected to the video output of a PC or notebook

and project images, screens, etc., on the wall. (My

back thanks him, as well, because now I don’t have

to lug the 32” monitor around.

Page 6