Moving from Visual FoxPro 3.0 to Visual FoxPro 5.0

Susan Graham
Microsoft Corporation

May 21, 1997

Overview

Most developers have had no problems moving their code from Visual FoxPro™ 3.0 to Visual FoxPro 5.0. There are, however, a few issues that you should be aware of before using Visual FoxPro 3.0 files in Visual FoxPro 5.0.

The object code was changed in Visual FoxPro 5.0. Therefore, you must recompile Visual FoxPro 3.0 Program (.PRG), Form (.SCX), Query (.QPR), Menu (.MPR), Report (.FRX), Database (.DBC), and Class Library (.VCX) files to run them in Visual FoxPro 5.0. The recompilation will occur automatically when each of these files is edited, instantiated, or run in Visual FoxPro 5.0.

Opening a Visual FoxPro 3.0 project in Visual FoxPro 5.0 automatically invokes the Converter (CONVERT.APP, located in the Visual FoxPro directory), which will then convert the project and all its contents. You can also open individual report and label files to start the Visual FoxPro 5.0 Converter. When you issue a command such as MODIFY CLASS or MODIFY FORM, Visual FoxPro 5.0 automatically recompiles and opens the file.

Issues

The following are issues you should be aware of when using Visual FoxPro 5.0 with Visual FoxPro 3.0 files.

The default settings for FontBold, FontSize, and ColorSource properties of objects are different in Visual FoxPro 5.0.

This change was made in order to conform to the Windows User Interface Guidelines. The converter gives you the option of maintaining the property values as they were in Visual FoxPro 3.0 or changing them so that forms and controls adopt the new Visual FoxPro 5.0 look.

Property	3.0 Default Setting	5.0 Default Setting
FontBold	True	False
FontSize	10 points	9 points
ColorSource	0	4

Label.Refresh( ) no longer occurs for Label.PARENT.Refresh( ).

In Visual FoxPro 3.0b, you could add a Refresh method to a label and add code in the label's Refresh method to "bind" the label to a "ControlSource." The label would automatically refresh its Caption on THISFORM.Refresh( ). The Refresh method no longer occurs in Visual FoxPro 5.0 for controls that don't have a native Refresh method.

Pages can receive the focus in Visual FoxPro 5.0.

Pages in PageFrames can receive the focus in Visual FoxPro 5.0 (the focus rectangle appears around a tab's caption). In Visual FoxPro 5.0, code that used to execute in the When or GotFocus event of the first control in tab order on a page no longer executes when the page receives the focus. This change was made in response to the numerous requests that pages be able to receive the focus. If your application expects the first object on a page to receive the focus, you can set the focus to the first control by placing the following line of code in the Activate event of the page:

KEYBOARD “{TAB}” PLAIN

Alternatively, you can place this code in the Activate snippet of the page:

THIS.Controls(1).SetFocus( )

You should use this only if you are sure that the first object on the page has a SetFocus method. If it doesn’t, Visual FoxPro generates a “Property is not found” error.

A form’s Init event occurs when a control’s Init event returns false (.F.).

In Visual FoxPro 3.0b, when a form's Init event returns False (.F.), the form's Init event never fires and the form isn't instantiated. In Visual FoxPro 5.0, when a control's Init event returns False (.F.), the form's Init event occurs—code you don't expect to execute does in Visual FoxPro 5.0.

This change is by design. It was determined that there are many more cases where developers prefer to create the form object if one or more Init events for controls on the form return false (.F). If you don’t want the form’s Init event to occur when an object’s Init event returns false (.F.), check for the existence of the control in the form’s Init event and return false (.F.) if the control doesn’t exist on the form.

IF TYPE("THISFORM.Control1")="U"
 * Control1 is the object that must RETURN .F.
 * exist to allow the form to run
ENDIF

In Visual FoxPro 3.0, if a base class didn’t have a ProgrammaticChange event and a Value property (there are several such classes), you could add them and they would act like the native ones.

Some developers made use of this unsupported feature to provide "SetAll( )" code execution, like "ExecuteAll(MyMethodName)" where the MyMethodName was a custom ProgrammaticChange event. For example, SetAll("Value", 0, "MyClass") for a Header object in a grid would fire code in all of the Header object's ProgrammaticChange methods. It didn't matter that the Value property was essentially meaningless to the Header object; it provided the ability to execute code that affected each header (and each column) in the grid without having to iterate through the columns.

In Visual FoxPro 5.0, this unsupported feature is no longer available, except where the ProgrammaticChange event and a Value property are available for a control or object.

Code that made use of this unsupported feature can be replaced by a FOR.. ENDFOR loop to iterate through the appropriate objects.

Visual FoxPro 3.0 behaved as if AutoYield were set to true (.T.).

Visual FoxPro 3.0 did not have an AutoYield property. However, it behaved as if AutoYield were set to true (.T.). In Visual FoxPro 5.0 the AutoYield property is set to true (.T.) by default.

The AutoYield property in Visual FoxPro 5.0 should be set to False (.F.) when a form contains an ActiveX™ control. Setting AutoYield to False (.F.) prevents events for an ActiveX control from executing between lines of user program code. For example, if AutoYield is set to True (.T.), clicking an ActiveX control while user program code is executing may cause an event for the ActiveX control to execute, ignoring the user program code for the event, producing undesirable or unpredictable results

Visual FoxPro 5.0 changes title bar colors in forms with menus created with DEFINE POPUP.

In Visual FoxPro 5.0, DEFINE POPUP changes the current form's title bar to the inactive title bar color. The title bar color did not change in Visual FoxPro 3.0b. Shortcut menus created in Visual FoxPro with the DEFINE POPUP SHORTCUT option don’t change the title bar color.

Closing a table with uncommitted changes performs a TABLEREVERT( ) in Visual FoxPro 5.0.

In Visual FoxPro 3.0b, if form uses buffering and you close the form while the buffer contains uncommitted changes, the form closes and an error message is generated. You must SELECT the table with the uncommitted changes and issue TABLEREVERT( ) before you can exit Visual FoxPro 3.0b.

In Visual FoxPro 5.0, the same scenario doesn't generate an error message, and an implicit TABLEREVERT( ) is executed. Because the error message isn’t generated, you might assume that the changes were committed. However, the changes are discarded. In Visual FoxPro 5.0 you should take care that applications utilizing buffering don’t allow forms to close without first resolving uncommitted changes.

COMPILE REPORT isn’t available in Visual FoxPro 3.0.

COMPILE REPORT, added to Visual FoxPro 5.0, isn’t supported in Visual FoxPro 3.0. Report and label files containing code compiled in Visual FoxPro 5.0 can be recompiled to Visual FoxPro 3.0 format with the following program. Copy the code below into a program file and run the program in the Command window, passing the name of the report or label file to compile as a parameter. See Usage and Example sections in the program header below for the format of the command you issue in the Command window.

******************************************************
*                 CONVREPO.PRG
*
* Program to compile Visual FoxPro 5.0 .frx or .lbx
* file to run under Visual FoxPro 3. This is necessary
* only if the report or label contains code in any of
* its DataEnvironment methods.
* 
* Usage: DO CONVREPO WITH <.frx or .lbx file
* including extension>
* 
* Example:  DO CONVREPO WITH "myreport.frx"
* 
******************************************************

LPARAMETER lcFrxName
LOCAL lcAlias, lcTmpFile
IF (TYPE('lcFrxName') = "C" AND;
UPPER('frx')$UPPER(lcFrxName)) OR ;
      (TYPE('lcFrxName') = "C" AND;
UPPER('lbx')$UPPER(lcFrxName))

   IF NOT FILE(lcFrxName)
      =MESSAGEBOX('The file '+ UPPER(lcFrxName) + ' ;
         does not ' + 'exist in the default ;
         directory. '+ CHR(13)+ ;
         'Please pass a valid report '+ ;
         'or label filename, including extension, ;
         to this program!' ,48, "Report/Label Code ;
         Compiler")
      RETURN
   ENDIF

   USE (lcFrxName)
   lcAlias = ALIAS()
   * Look for any Data Environment object's records
   SCAN FOR NAME='dataenvironment' ;
         OR NAME='cursor' ;
         OR NAME='relation'
      IF !EMPTY(TAG)             && Is there any code?
         lcTmpFile = SYS(3)
         COPY MEMO TAG TO (lcTmpFile+'.PRG')
         * Copy to temp .prg
         COMPILE (lcTmpFile)      && Compile it
         APPEND MEMO tag2 ;
            FROM (lcTmpFile+".FXP") OVERWRITE 
            * Write it back to .frx/.lbx
         ERASE (lcTmpFile+".PRG") && Delete temp files
         ERASE (lcTmpFile+".FXP")
      ENDIF
   ENDSCAN
   USE IN (lcAlias)
   SET MESSAGE TO "Recompile completed"
   WAIT "" TIMEOUT 2
   SET MESSAGE TO
ELSE
   =MESSAGEBOX('Please pass a report or label ;
      filename, '+ 'including extension, to this ;
      program!' ,48, "Report/Label Code Compiler")
   RETURN
ENDIF
RETURN
*
* End of CONVREPO.PRG

Additional Conversion Considerations

Here are some additional things to consider when converting your files:

BUILDAPP.PRG, a tool included with Visual FoxPro, strips the method and event code of .SCX and .VCX files from .APP and .EXE files for distribution. BUILDAPP.PRG isn't required in Visual FoxPro 5.0. Source code is automatically stripped from .APP and .EXE files if you uncheck the Debug Info checkbox in the Project page of the Project Information dialog box.
In Visual FoxPro 5.0, the AFIELDS( ) function creates an array with 16 columns, providing more information about the structure of a table. In Visual FoxPro 3.0, AFIELDS( ) creates an array with only 11 columns. See the AFIELDS( ) topic in the Help file for additional information about the additional columns.
Some bitmaps that displayed properly in Visual FoxPro 3.0 might not display properly in Visual FoxPro 5.0. If a bitmap doesn’t display properly in Visual FoxPro 5.0, use ImageEdit to edit the bitmap by changing at least one pixel and then save the bitmap.

Using Visual FoxPro 3.0 and Visual FoxPro 5.0 Simultaneously

To use Visual FoxPro 3.0 and 5.0 at the same time, do the following:

Create different projects, one for each version. Note that the files you reference in each project can be the same.
Before you modify any files in the project or build an application from the project, rebuild the entire project with the Recompile All Files option checked in the Build Options dialog box.
Avoid using Visual FoxPro 5.0–specific features.
Be aware of some of the differences between Visual FoxPro 3.0 and Visual FoxPro 5.0 described above. Try to avoid the differences or add DO CASE statements based on the version number with additional code for the respective versions.

A related Knowledge Base article, "HOWTO: Converting VFP Files from Version 3.0 to 5.0 and Back" (Article ID: Q162076), discusses moving between Visual FoxPro 3.0 and 5.0 and can be found on the MSDN Library.

Summary

The move from Visual FoxPro 3.0 to 5.0 should be very smooth and well worth the effort. Visual FoxPro 5.0 adds improved performance, a new debugging environment, and OLE automation, as well as new database features. For additional information about Visual FoxPro 5.0 and moving from Visual FoxPro 3.0 to 5.0, visit the Visual FoxPro Web site at http://www.microsoft.com/vfoxpro/.

Acknowledgments

Drew Speedie, Mac Rubel, Lisa Slater Nicholls, Paul Maskens, Mike Feltman, Rainer Becker, Rick Strahl, Ken Levy, Jim Saunders, Calvin Hsia, and Ken Tittle all contributed to this article, pointing out issues, offering code, and suggesting changes.