Database development and training for Birmingham and the midlands
Specialists in Microsoft Access and Visual Foxpro database training and development
I am happy to hear from existing clients but I am taking no new calls.
Converting FoxPro 2 screens
Converting the screens of FoxPro for Windows into the forms of Visual FoxPro is the most difficult part of the process.
The Screen Builder in FoxPro 2 saved the graphical design in a pair of files with .scx and .sct extensions and you then had to use a further option to generate a .spr program file from these tables. The Form Designer in Visual FoxPro generates a pair of files with similar names but their content is very different. They hold the definition of the objects in the form and the Do Form command uses these files directly.
Visual FoxPro can open screen files from FoxPro 2 and convert them into the newer format. If you open a FoxPro 2 screen in Visual FoxPro then you get a dialog with two options,and .
Neither of these options is really satisfactory and they do not represent the full range of possibilities. In fact you have four choices:
- Functional conversion
- Visual conversion
- Do Nothing and run the old spr program files
- Rewrite the form completely
Functional Conversion gives a form that will run in Visual FoxPro but in order to be able to cope with any possible situation in FoxPro 2, it will convert even the simplest form into a Page of a PageFrame on a Form in a FormSet. This means that instead of one simple form you will have three nested containers and a design which is far too complex for the vast majority of screens.
The FormSet has a WindowType of 2 or 3 and textboxes on the form have a Style of "2.x @SAY Compatibility". Both these options only exist for forms which have been automatically converted from Fox 2 and so Functional Conversion takes you away from the main stream of VFP development into a dead end. Any further work you do will have to work in this peculiar subset of Visual FoxPro.
Visual Conversion gives you the layout of the form in the usual two files but puts the logic in a separate program file. As with the Functional Conversion, the form files represent a form inside a form set and it too is overcomplex for most forms. Neither the form nor the program will run without some further manual work.
All the code snippets from the FoxPro 2 screen are saved in a .prg file with the same name as the form. There is not an exact match between the snippets of FoxPro 2 and the methods of VFP. Functional conversion forces the snippets into some non-standard features of VFP but Visual Conversion avoids this compromise by saving the program code of the snippets in a separate file and allowing the developer to decide how the logic should be implemented as methods of the new form.
Visual conversion requires more work from the developer and leads to a better solution but the VFP design still includes the unnecessary form set.
Doing nothing is an attractive option and can work well as a short-term solution. The two automatic conversions above work on the FoxPro 2 screen data files but the layout and behaviour of the screen also exists in the FoxPro 2 database in a non-visual form as a FoxPro program with a .spr extension. This program uses @SAY commands to display the data and graphical elements of the screen and the @GET command to accept input from the user. These are marked as "backward compatible" elements in Visual FoxPro but they will still work.
You should be able to make the minimal alterations to the program code described here and then just run the spr file as a program. You will have lost all links to the visual design tools and you will have to make any changes by using the old FoxPro 2 syntax but this might be the best strategy for a form in a little-used area of the application.
In an ideal world, this would be the best solution. The old screen design will have been done to the standards of Windows 3 and will look very old- fashioned in the XP world. It will probably have a white background and the text will be in a bold MS Sans Serif font. You can of course work through the converted forms and modify the backgrounds and fonts but you will still have a design from the mid-nineties.
The logic behind the forms will also be dated. The code will have had ten years of maintenance and at best you will be faced with a complex structure of bug fixes and patches. At worst you will have a mess which defies understanding. Take this opportunity to use the best from the existing design and to build a new structure.