The LA Fox Developer

The LA Fox Developer Newsletter

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 converted forms and their objects without individually modifying each one.

(2) GENSCRNX and other add-ons - Many developers 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 applications 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 developers to integrate browses with screens, and to manipulate between multiple windows in a screen set Due to inherent differences between VFP and FPW2.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 straightforward. 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 converted 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 Functional 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-compatible 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 yOudesign 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 consented 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.