Converting FPW 2.6 to Visual FoxPro

1
Converting FPW 2.6 to Visual FoxPro

• David Bower
• Quids Technology Pty Ltd
• dave_bower_at_msn.com.au

2
About Me

• 20 years experience in dBase, FoxBASE, FPD, FPW
  and VFP
• Managing Director of Quids Technology
• Developer of Quids merchandising systems with
  over 150,000 lines of FPW 2.6 code and 400
  concurrent users.

3
Why Another Converter?

• The standard converter generates unmaintainable
  code
• Avoid development downtime
• Avoid costs of a manual rewrite (read
  re-development)
• For consistency and accuracy of conversion

4
The Goal

• To produce code which is as close as possible to
  that which we would desire using a manual
  conversion.
• We are NOT aiming for complete code conversion,
  because that goal would compromise the result.

5
The VFP Standard Converter

• There are 2 existing conversion options
• 1. Visual Conversion
• Intended to provide a VFP runtime version with
  minimal pain, but with no upgrade path
• It does this by simply running the .SPR files as
  they were in FPW!
• So not really a converter, but a legacy option.

6
The VFP Standard Converter

• 2. Functional Conversion
• Provides useful output
• The layout and naming of the controls and the
  appropriate base class.
• The methods and properties are generally correct.
• The converter does generate an SPR style wrapper
  program for each form.
• A project file (PJX) is generated which contains
  most of the material we need.
• Reports are converted too.

7
The VFP Standard Converter

• The biggest problem of the standard converter is
  that
• It uses special form modes for backward
  compatibility with the old READ command to
  support the SHOW GET(S) used so heavily in FPW.
• This is in essence why we need a better converter.

8
The New Approach

• Prepare the FPW code
• Standard VFP functional conversion
• Phase 1. Traverse the project(s)
• Build function and file lists
• Convert forms and objects classes to our own new
  classes
• Phase 2. Traverse the Code
• Build form context
• Phase 3. Recompile
• Perform syntax conversion
• Custom conversions

9
Preparing for Conversion

• Variable Scope.
• Move variables instantiated in Section 2 of
  screen Set-up to Section 1.
• Project Integrity.
• The FPW2.6 project should fully rebuild itself.
  Check Do ( and Do
• Add all reports to the project
• Data Environment. Dont use it.
• Screen Names.
• Name every screen in your FPW2.6 projects with a
  unique name.

10
The Standard Conversion Process

• Ready to go?
• Backup!
• Replace the Foxuser files.
• Replace .fll files with VFP versions and update
  code references.
• Create dummy wrapper modules for external apps.
• Rebuild all 2.6 projects
• Use the Functional Conversion.
• Set the home directory.

11
Standard Converter Issues

• Variable scope.
• Colorsource error.
• SPR and MPR file behaviour under VFP.
• .App files without source code.

12
The New Converter Interface

• Setup
• Options
• File Menu tools and utilities
• Three Phases

13
Phase 1 - Traversing the Projects

• Recursively processes all projects in the
  application
• Builds File and Function lists complete with
  source code for later use.
• But most importantly
• Converts the forms to new base classes

14
Form and Object Class Conversion

• The ClassMap.dbf table
• Provides all the information required to convert
  both forms and form objects to new base classes
• Allows for powerful soft-coded reconfiguration of
  the object properties
• Allows mapping of one FPW object class to many
  VFP base classes. E.g. Modal and Modeless forms.

15
Phase 2 - Context Analyser

• Uses the File and Function lists to traverse
  through every line of code building Form, Menu
  and procedure references.
• Builds references to the form names for every
  file and function for use by the recompiler.

16
Phase 3 - Recompiler

• Uses data-driven code to perform syntax
  conversion (Syntax.dbf)
• Modifies the source code in all Program, Form and
  Menu files to remove FPW READ dependencies
• Applies any other code conversion we see fit to
  include in Syntax.dbf
• Able to insert comments into code for problematic
  syntax
• Creates custom form methods for identifiable
  functions

17
Syntax Conversion

• SHOW GET, SHOW GETS and CLEAR READ commands in
  FPW are not explicit in identifying the Form. FPW
  simply applies them to the active form.
• We need to establish the form context and
  identify the matching VFP object to allow
  rewriting as object methods
• Examples follow

18
Syntax Conversion Examples

• SHOW GET m.pb ENABLE
• W_Form.cmg12.command1.enabled.T.
• SHOW GET m.rb,2 PROMPT Bulk Ship DISABLE
• W_Form.opt12.option2.captionBulk Ship
• W_Form.opt12.option2.enabled.F.
• CLEAR READ
• _screen.activeform.release()
• SHOW GETS OFF
• _screen.activeform.refresh26()
• SHOW GETS ONLY
• _screen.activeform.refresh()

19
Modal, Modeless and READ EVENTS

20
The Finished Product?

• We now have a VFP version of our original FPW
  code ready to take advantage of all the great new
  features in VFP
• We do still have issues with modal/modeless forms
  and particularly formsets which need manual
  intervention

21
The Finished Product

• The real beauty is that, if testing reveals
  issues, you can modify the converter and quickly
  re-run the whole conversion.
• All the while you can continue to enhance the FPW
  production code, right up until the point where
  you are satisfied with the conversion utility

22
Conclusion

• The aim has been to produce a conversion which
  provides VFP code as a basis for moving forward
  without affecting the ongoing development process
• We now have a conversion mechanism which not only
  achieves this but significantly reduces the time
  and cost, and improves the reliability, accuracy
  and consistency of the code compared to any
  manual conversion

23
Questions?

• (dave_bower_at_msn.com.au)

24
Updated Version of Presentation

• www.ozfox.com.au
• This session will have web updates

25
Thank You

• Dont forget to complete your session evaluation