Converting Your Existing Applications to Visual FoxPro 3.0

Thinking of converting your existing FoxPro 2.6 applications to Visual FoxPro 3.0? Check here for information on how to start using the new Visual FoxPro 3.0 features while still leveraging your existing development investment.

Introduction
Converting Projects
Visual Form Conversion
Deciding Between Visual or Functional Conversion
What Can Cause Conversion Problems
Conclusion


Introduction

Visual FoxPro 3.0 has opened up a wealth of new developer tools that can only be considered as revolutionary for the FoxPro programmer. From object orientation to visual form and class tools, the whole application scheme has been revamped. Even though the Visual FoxPro environment provides a whole new way of doing things, your existing FoxPro 2.6 application can be almost seamlessly integrated into this brave new developer environment. The expansiveness of the new Visual FoxPro features can be daunting, but this is mitigated by the conversion utilities built into the product. This paper will look at how you go about converting your existing 2.6 application in Visual FoxPro. With this conversion you can start using these wonderful new features while still leveraging your existing development investment.

Successful conversion of an application requires planning how the components of the application will be converted. The decision process is two-fold. First, it must be decided if you want to take the default, Functional conversion, that completely converts the 2.6 screen to a backwardly compatible Visual FoxPro form set, or Visual conversion, which entails running the 2.6 coded .SPR file and manually implementing the converted form set. Secondly, decisions have be made on how you wish to incorporate the new extensions found in Visual FoxPro. The second question directly affects the first, of Visually or Functionally converting your screens. However, no matter what conversion route you choose, the conversion will run your existing application AS IS, in the new Visual FoxPro environment.

The areas affected by conversion include projects, forms, reports, labels and code. The most intensive area is what used to be known as screens in FoxPro 2.6 and are now known as forms in Visual FoxPro. However, we will take a top down approach by looking at converting a project first and then working our way through the other components.

---

Converting Projects

Conversion of a project from 2.6 to Visual FoxPro starts by opening the 2.6 project in Visual FoxPro. Visual FoxPro will recognize the file is a 2.6 .PJX file and process it through the CONVERT.APP application. This CONVERT.APP application is installed by default in the Visual FoxPro home directory. Upon starting the conversion utility, a dialog box, as depicted below, is presented to the developer.



This conversion dialog box is very much like the dialog box that is presented to you when you open a non-converted 2.6 .SCX screen file.

The first option of the dialog box relates to if and where backup copies of pre-converted 2.6 screen sets are copied to. Before converting the 2.6 screen to a Visual FoxPro form, CONVERT.APP will create a directory OLD, off of the designated one.

The second option allows the specification of a log file. This is a text file with the suffix .LOG and contains a recap of the conversion process. The information includes: if conversion took place, elapsed time of the conversion, whether the conversion was successful or not, and error messages related to unsuccessful conversion. If problems occur during conversion, this log will be the source of detail for those errors.

Selecting Functional or Visual conversion is the area of most concern for the developer in converting their applications. Both conversion methods allow you to simply convert your application, build it and the run the resulting .APP or .EXE file, the differences between the methods come into play when you start implementing and extending the converted form.

The Functional conversion creates the most hands-off type of conversion, but can cause more work when extending your existing application with the new features built into Visual FoxPro. With Visual conversion, the forms in the application are better prepared to take advantage of new Visual FoxPro features, but require manual placement of the code behind the forms. The project implements these two methods in two very distinct ways. We'll first look at the differences in the conversion methods as they relate to the project and then follow up with a detailed look at how forms are converted differently under the two methods.

When Functional conversion takes place, the forms are converted and the converted forms are called within the application. Under Visual FoxPro the code to call a form is DO FORM ; in FoxPro 2.6 the syntax is DO .SPR. The converter does not modify the original calls to the forms, but creates a corresponding SPR file that executes a DO FORM . Here's what the CUSTOMER.SPR program looks like after Functional conversion takes place, as executed with a DO CUSTOMER.SPR:

*- CUSTOMER.SPR

*- [CONVERTER] Declare variables for record pointers

PUBLIC _iconvCustomerGoToPlaceHolder

DO FORM "CUSTOMER.SCX" NAME _R2716LSBP LINKED 

*- [CONVERTER] Begin CLEANUP and other procedures from 2.x Form

PROC CLEANUPSAMP

WAIT WIND 'nada'

*- [CONVERTER] End CLEANUP and other procedures from 2.x Form

Note that a public variable is initialized. This variable is filled with the current record number during the Unload event of the form, to be used to reset the record pointer when re-entering the form. Additionally, any procedures or functions that existed in the 2.6 cleanup code are placed into this .SPR file. Unlike a standard Visual FoxPro form, this form emulates a 2.6 READ and creates a wait state while the form is running. The program does not finish executing until after the form is released, thereby giving the form access to procedures and functions contained within the calling .SPR program.

A Visual conversion differs in that although the screen is converted, the SPR is not overwritten with the code demonstrated above. The SPR remains the same as it was in 2.6 and is simply recompiled. The converter doesn't make assumptions about where to place code snippets in the new Visual FoxPro form set, but rather writes them out to a program file. The new Visual FoxPro form will not run if it is dependent on these disembodied snippets. To make the form functional, there needs to be some interaction by the developer, first in calling the form with a DO FORM and then placing the code snippets in their correct events of the form.

Converting from the project level is the most desirable way to convert an application. Not only does it convert all components of an application, it is the only method that will convert multiple screen sets into a Visual FoxPro form set.

Form Conversion

Form conversion can be invoked by opening a 2.6 screen or electing to convert a project that contains screens. Either method presents the developer with the election of executing the default Functional or optional Visual conversion. The resulting forms from each conversion method differ in several ways. The resulting forms from a Functional conversion result in a complete working form that respects all facets of the previous 2.6 environment. The Visually converted forms require the developer to manually place code snippets where appropriate.

Functional Form Conversion

Functional conversion creates a form set and places all the controls from the 2.6 screen onto a Visual FoxPro form within a page frame container. Each page frame relates to an individual READ in the predecessor 2.6 screen, so if the screen was created in 2.6 with multiple READs, they would each correspond to a page frame in the converted Visual FoxPro form. Even though multiple READs in a single screen were not common in version 2.6, the Functional conversion takes their possible implementation into consideration and can be considered one of the major drawbacks of this method.

The most important setting in the Functionally converted form is the form set's WindowType property. If the value of this property is 2 or 3 then the form set takes on the READ qualities of a 2.6 screen set. Execution stops when a DO FORM or SHOW command calls the form. The WindowType value of 2 is a normal form set which can be deactivated; a value of 3 makes the form modal so that it must be released before execution can start again. These WindowType properties relating to 2.6 screen compatibility are only available with Functionally converted 2.6 screens. When screens are converted Visually or are created in Visual FoxPro, this WindowType property only relates to standard Visual FoxPro modeless and modal behavior and does not allow the backwardly compatible settings of 2 and 3. The only time you will see form set WindowType properties with READ capabilities is in a Functionally converted form set.

Code is moved from the 2.6 events to Visual FoxPro events in a specific pattern. The following is a table of the conversion of 2.6 events to Visual FoxPro events.



FoxPro 2.6 Screen Event	Converted Visual FoxPro 3.0 Event
Setup - #Section 1	FormSet.Load
Setup - #Section 2	Form.Load
Activate	Form.Activate & FomSet.Activate
Deactivate	FormSet.Deactivate
Show	FormSet.ReadShow
When	FormSet.ReadWhen
Valid	FormSet.ReadValid
Cleanup	FormSet.Unload & SPR for procs/functions

The READ keywords CYCLE, LOCK, MOUSE, SAVE, and TIMEOUT are moved to form set properties with the names ReadCycle, ReadLock, ReadMouse, ReadSave, and ReadTimeout.

A behavior unique to this backwards-compatible screen relates to variable scoping. Variables that are defined in the Load event are scoped to the life of the form. This is for compatibility reasons only and does not conform with standard Visual FoxPro variable scoping

It should be noted that environmental settings are automatically defined in the form set Load event and the current record pointers are saved in public variables during the form set Unload event. The data environment of the form is updated with all appropriate 2.6 view environment objects such as the table aliases, index orders, and relationships. The 2.6 generator directives for automatically opening and closing the tables are moved to the properties AutoOpenTables and AutoCloseTables in the DataEnvironment object.

Extending a Functionally-Converted Form

The following steps are a program for extending functionally converted forms into a Visual FoxPro format. By definition, the functional conversion creates a backwards-compatible form set. By applying these steps to the situations that apply to the particular form, you can change the backwards-compatible form set into a standard Visual FoxPro form set. This conversion process is an excellent learning tool for the 2.6 programmer moving to Visual FoxPro.

1.Move parameter code from the Load event to the Init event.
2.Change form-level variables to user-defined form properties.
3.Create form methods for form-specific procedures and functions (those moved to the SPR).
4.Change CLEAR READ to RELEASE THISFORMSET or RELEASE THISFORM.
5.Change SHOW GET to <object>.Refresh.
6.Change SHOW GETS to THISFORM.Refresh or THISFORMSET.Refresh.
7.Change SHOW GET for List and Combo boxes to <object>.Requery.
8.Move READ SHOW and READ WHEN to the form set Load event.
9.Move READ ACTIVATE and READ DEACTIVATE to the form set Activate and Deactivate events.
10.Move READ VALID to the QueryUnload event.
11.Convert foundation READs to READ EVENTS and CLEAR EVENTS.
12.Change the WindowType property to 0 or 1.



---

Visual Form Conversion

Visual conversion approaches form conversion in a Visual FoxPro related paradigm, as opposed to the backwards-compatible one in Functional conversion. The resulting form set and forms mimic a standard Visual FoxPro form set arrangement, while the Functional conversion mimics 2.6 behavior. There are no page frame containers in the Visually converted form and the form set WindowType property is set to 0 for modeless or 1 for modal. Unlike the Functionally converted form, execution does not stop when the form is called with a DO FORM or SHOW command.

The most significant difference between the two conversion methods, at least as it relates to developer interaction, is that Visual conversion does not place any code snippets into form events. When conversion takes place the code snippets are separated into a PRG file so they can be implemented visually by the developer into the converted form. An example of this PRG file shows a converted 2.6 push button valid snippet that calls a search screen.

*----------------------------------------------

*- Code from C:\jfhapp\screens\JCONT1.SCX

*----------------------------------------------

*----- cmgOption1

PROCEDURE Valid

   DO search.spr

ENDPROC

After code is placed from the conversion PRG into the form, the developer needs to integrate the form into the application. To implement the converted form into a project, the call to the screen needs to be changed from DO .SPR to DO FORM or the SPR needs to be changed to explicitly call the form with a DO FORM command. Remember that miscellaneous procedures and functions from the 2.6 screen cannot be put into the .SPR file since launching the form does not stop execution under standard Visual FoxPro behavior. These items need to be added to a PROCEDURE file or implemented within the form as methods. Note that if procedures are implemented as form methods, the calls to the procedures must change also.

---

Deciding Between Visual or Functional Conversion

When executed through the Project Manager, both Visual and Functional form conversion end up with a FoxPro 2.6 application running in Visual FoxPro 3.0. The difference is that with Functional conversion, the forms that run in the application are the actual converted forms. With Visual conversion, the original 2.6 SPR is running in the application. Since the initial result is the same, the question of which method to select comes down to how extensive the maintenance to forms is expected in the future. If future maintenance can be expected to be minor and cosmetic in nature, then Functional conversion would be a logical choice. If larger scale changes to the forms can be foreseen, then the developer might opt for a Visual conversion that will allow a complete implementation of the new Visual FoxPro model. A very important point to remember is that the Visually converted form does not contain the page frame controls that the Functionally converted one does.

Through project conversion you cannot selectively convert some screens Visually and others Functionally. Project conversion is an all-or-nothing proposition. This can be somewhat mitigated by being able to selectively convert forms, after the fact, from the backup OLD directory. Of course, screen set properties, such as multiple screens, are only available through the project manager. If a hybrid method of converting forms is required, consider doing two separate project conversions and mixing and matching the results.

No matter which method is selected. It should be noted that the extension of a Functionally converted form to a Visual FoxPro format is an excellent learning tool and should be investigated if only for that reason.

---

What Can Cause Conversion Problems

Be careful with macro substitution in properties. For example a 2.6 push button prompt of &buttonprompt will be converted to ="&buttonprompt" in the Visual FoxPro caption property of the converted command button. This needs to be changed to "=buttonprompt" in the property sheet.

It is possible to have a conflict in the Visual FoxPro naming convention by having a long variable name with 10 common characters.

There are new reserved words in Visual FoxPro. If you run into an unexplainable problem with certain code, check it against the reserved word list found in the help file.

Overlaying of controls is handled differently. If the resulting appearance is not as desired, consider reordering the objects and using the Zorder method.

Reports and Labels

The only significant modifications to version 2.6 FRX and LBX files are the addition of additional rows to contain information related to the DataEnvironment object.. If the report or label was saved with an environment in version 2.6, the AutoOpenTables and AutoCloseTables properties in the DataEnvironment object are set to .T. and table aliases, index orders, and relationships objects are added to the DataEnvironment object.

Extending Existing Code

The Grid control has taken over as an objectified browse, so that future browse type implementations will be grid-based. However, your existing browse code can be objectified through the use of the NAME keyword. You can define the browse NAME object and then manipulate the browse in an object-oriented Visual FoxPro fashion. Here is an example of objectifying a browse using the NAME keyword and then changing the BackColor property of the objectified browse to turn the background color of the browse red.

USE customer

BROWSE NAME oBrowseGrid

oBrowseGrid.BackColor=RGB(255,0,0)

This new named object can be manipulated just like a grid object. Your existing browses can easily be extended to include dynamic colors, combo box or spinner column controls, and so on. All capabilities of the new grid control can be added to your existing browse, with very little coding.

This same NAME keyword is available for all the @...GET commands so existing code for the objects on forms can be objectified just like the browse command.

dBASE and FoxPro for MS-DOS

The conversion utilities work the same with dBASE forms and reports. If you are converting from a FoxPro platform that would require conversion to FoxPro for Windows, such as FoxPro DOS, the FoxPro for Windows transport utility will first transport to Windows objects and then convert to Visual FoxPro.

---

Conclusion

The conversion capabilities built into Visual FoxPro allow the FoxPro 2.6 developer to easily move their existing applications into the new visual and object-oriented Visual FoxPro development environment. Whether the conversion is functional or visual, the existing 2.6 application will run virtually untouched in Visual FoxPro. Using the visual tools, class libraries and code extensions, the developer can learn how to add Visual FoxPro functionality to their already running application, thereby learning this brave new world while still leveraging their existing investment.

Moving from FoxPro 2.x to Visual FoxPro 5.0

This paper discusses converting your FoxPro 2.x code to the new object-oriented programming (OOP) paradigm of Visual FoxPro 5.0 and offers different approaches according to the issues you face.

Introduction
Approaches
Converting FoxPro 2.6 Projects
Modifying 2.6 Reports
Moving a Foundation READ into Visual FoxPro
Other Gotchas
Table and Database Differences
Use information from your 2.6 application
Summary

Introduction

Ever since the release of Microsoft® Visual FoxPro™ there has been continuous discussion among Fox developers about the pros and cons of moving FoxPro® 2.x code into the new object-oriented programming (OOP) paradigm. Should one convert the 2.6 code? Should one just throw it all away and rewrite everything? The purpose of this paper is to:

· Give you some issues to think about in your decision-making process.
· Present several approaches to converting your apps, if that's what you want to do.
· Provide information about the conversion process.

Convert or Rewrite?

If it ain't broke…

If your FoxPro 2.x application has been running well — it's been through several versions, it's stable, and needs no new functionality — you need to ask yourself if there is really a reason to take the time and effort to migrate that application to Visual FoxPro. However, since the reality of most development projects is that they are never finished, you need to consider the advantages and disadvantages of the conversion process to determine which path is right for your application: convert or rewrite.

OK, it ain't broke, but…

You want to move your applications into Visual FoxPro so that you can begin to take advantage of OOP, the new development environment, and the new database features of Visual FoxPro 5.0.

Most FoxPro version 2.x programs coded in traditional procedural style will run with minor modifications in Visual FoxPro. Conversion is a viable option for some developers.

Consider making the transition to an OOP programming style if the following conditions are true:

· Your organization currently participates in a structured, analytical process for new programming projects.
· You are willing to invest the resources necessary to develop a library of reusable code, without realizing full payback on this investment until after the current project.
· You want to tap the power of Visual FoxPro event handling, common code syntax, and other benefits associated with OOP.

Issues to consider

Here are some issues to consider before deciding whether to convert:

· Is your application written in FoxPro (or FoxBase) standard procedural code?

· Does your application use FLLs? If so, do you have the resources (source code, development language of the FLLs) to recompile them?

· If you are using third party tools, have they been converted to Visual FoxPro so that you can maintain the same functionality? If not, does Visual FoxPro 5.0 now provide the functionality provided by those tools?

· Is your application cross platform to MS-DOS®, Unix, or Macintosh? Does it need to continue to be?

· Will you present this as a 5.0 application (a 2.6 paradigm in a totally new OOP world)? Do you need the Windows® 95 look and feel?

· Do you and/or your clients have a 32-bit operating system such as Windows 95 or Windows NT? This is a requirement for Visual FoxPro 5.0.

· Do you need to expand the application? Add new functionality? Do you want to take advantage of the new functionality of Visual FoxPro 5.0 such as ActiveX controls, the event model, data buffering, OLE automation server capability, offline views, outer joins, and so on?

---

Approaches

Once you have decided to migrate your application from FoxPro 2.x to Visual FoxPro, there are three basic approaches you can take:

Approach	Advantages	Disadvantages
Minimalist - Compile and run - no conversion	Least amount of work to get apps running in 5.0 No further development time and effort	FP 2.6 architecture, not OOP Old User Interface, not Windows 95 UI Cost of maintenance/ improvement may be high
Hybrid - Convert and modify	Old code still usable Begin to take advantage of new OOP functionality Take advantage of new VFP 5.0 functionality UI gets new look and feel (end user sees a difference)	Mix of 2.6 and 5.0 paradigms Hard to maintain
Total rewrite	More powerful design tools Database features Tap the power of VFP 5.0, such as event handling, common code syntax, and other benefits associated with OOP	OOP learning curve Re-architect your application Investment of time and money

Approach 1 Minimalist - Compile and run - no conversion

Your existing FoxPro 2.6 application should compile and run with few problems if you follow these steps:

1. Create a new project in Visual FoxPro 5.0.
2. Add your main PRG. (Note: Do not use an SCX as your main program. If you do, Visual FoxPro 5.0 will invoke the Converter.)
3. Build the project.
4. Add files not pulled in by the Project Manager (bitmaps, #includes, etc.).
5. Build your application.

Using this minimal approach allows you to continue running mission critical applications as you take the time to move into the new OOP paradigm. Approach 2 Hybrid - Convert and modify

This approach uses the Visual FoxPro Converter to "migrate" your 2.6 screen sets to backwardly compatible Visual FoxPro form sets (as opposed to New Event Model form sets). Once screens are converted, continue the conversion so they become "true" Visual FoxPro forms that are able to use the new event model and other features. More on this later.

---

Converting FoxPro 2.6 Projects

Converting from the project level is usually the desirable way to convert an application. Converting a project handles everything at once and is really the only way to change multiple screen sets into a Visual FoxPro form set. The alternative is to convert individual screens, reports, etc. one at a time. This has the advantage of allowing you to move the process along more carefully. It also makes it possible to selectively convert some screens with the Visual conversion, some with the Functional conversion (see below).

If you have used the Power Tools in FoxPro 2.6, the following FoxPro file types will convert:

· Labels (.lbx)
· Queries (.qpx)
· Menus (.mpx)
· Reports (.frx)


Reports

DOS reports will only run unconverted, as in FoxPro 2.6 for Windows; you cannot edit DOS reports in Visual FoxPro.

Genpd.app can be recompiled and run, but Visual FoxPro will not support these printer drivers. The functionality has been replaced in the operating system.

Take note of the new functionality of the REPORT FORM command. See the Help file for REPORT FORM…ASCII and REPORT FORM…PREVIEW.

CONVERT.APP

The Convert.app application is installed by default in the Visual FoxPro home directory. Because it would have been impossible to account for all the possible conversion issues, the source code for the compiler is distributed with Visual FoxPro in the \VFP\Tools\Convert directory. You can customize it for your particular needs, just set the system variable _CONVERTER to your version of the Convert.app.

When you attempt to modify a 2.6 screen or project, Visual FoxPro 5.0 detects the older version and automatically loads Convert.app and displays this screen:



Even though there is an option to save backup files in a directory named "Old", it is a better idea to work on a copy of your original 2.6 files rather than rely on the \Old directory. The primary reason for this is the path issues that you'll have to deal with when your directory structure is changed to include a top level \Old directory.

Choosing between Functional or Visual conversions is one of the most important decisions you must make.

The Functional conversion makes it easier for the developer in the short run, but can require more work to take advantage of the new features of Visual FoxPro 5.0. The Converter makes forms backward compatible, with attributes unique to this type of form (more later).

The Visual Conversion duplicates in Visual FoxPro 5.0 all visual components of a project (forms, buttons, and so on), but none of your existing snippet code (Open, Valid, etc.). All the code from the original FoxPro 2.6 snippets is copied to a non-compilable .prg file. You will have to cut and paste your procedural code into the appropriate events and methods of the Visual conversion. But you won't have to modify the converted form to take advantage of the new event model.

If you choose Functional conversion, the conversion process performs these steps:

1. Copies the original project files to a new subdirectory named Oldx in the original .pjx directory and automatically increments x as you convert more projects.


2. Converts the project and all associated screens, reports, and labels to Visual FoxPro format. New forms have the .scx and .sct extensions. Original files are given .s2x and .s2t extensions.


3. Moves code snippets to appropriate event and method code.

The following table summarizes how 2.6 screen events are converted to VFP 5.0.

FoxPro 2.6 screen event	Converted Visual FoxPro 5.0 event
Setup - #Section 1	FormSet.Load
Setup - #Section 2	Form.Load
Activate	Form.Activate & FomSet.Activate
Deactivate	FormSet.Deactivate
Show	FormSet.ReadShow
When	FormSet.ReadWhen
Valid	FormSet.ReadValid
Cleanup	FormSet.Unload & SPR for procs/functions

 

The READ keywords CYCLE, LOCK, MOUSE, SAVE, and TIMEOUT are moved to FormSet properties with the names ReadCycle, ReadLock, ReadMouse, ReadSave, and ReadTimeout.

Form Sets and Control Properties

The Converter creates a file with an .spr extension for each converted screen. This file is different from a FoxPro 2.6 .SPR file. In FoxPro 2.x, the .spr file was generated code based on what was found in the .scx. In Visual FoxPro, the .spr file is a "wrapper" file that includes the correct DO FORM command required to run the screen code. Here is an example of the .spr created after converting Laser.scx from the FoxPro 2.6 samples:

*- [CONVERTER] Declare arrays

EXTERNAL ARRAY ltags
EXTERNAL ARRAY rats
EXTERNAL ARRAY studs
EXTERNAL ARRAY titlelist


*- [CONVERTER] Declare variables for record pointers

PUBLIC _iconvLaserGoToPlaceHolder

EXTERNAL PROC laser.scx

DO FORM "laser.scx" NAME _RH21148KX LINKED 

*- [CONVERTER] Begin CLEANUP and other procedures from 2.x Form



PROCEDURE setltags

DIMENSION flds(256), ltags(256)
ltags(1) = "Record#"

FOR i = 2 TO 256

	IF LEN(TAG(i-1)) = 0
		i = i - 1
		DIMENSION ltags(i)
		EXIT
	ELSE
		ltags(i) = TAG(i-1)
	ENDIF

ENDFOR

ord = "TITLE"

SET ORDER TO TITLE

SHOW GET ord


*- [CONVERTER] End CLEANUP and other procedures from 2.x Form




Using the DO FORM Command

The DO FORM command has two very useful clauses: NAME and LINKED. The NAME clause specifies a variable or array element with which you can reference the form or form set. However, if you specify a variable that doesn't exist, Visual FoxPro automatically creates it. When you specify an array element, the array must exist before you issue DO FORM. If the variable or array element you specify already exists, its contents are overwritten.

If you omit the NAME clause, Visual FoxPro creates an object type variable with the same name as the form or form set file.

Include LINKED to link the form to the variable associated with it so that the form is released when the variable goes out of scope. If you don't include LINKED, a form can still be active, even though there is no object variable associated with the form.

The Converter places these files in the following locations in the Project Manager.

FoxPro 2.6 files	Project Manager tab
.prg and .spr files	Code tab
.scx and .sct files	Documents tab
.frx and .lbx files	Documents tab

 

In the Functional conversion, each converted form is in FoxPro 2.6 READ-compatibility mode. Each form set contains one page frame that contains one page for each read level of the original screen. This format was necessary to account for any and all READ LEVELS your FoxPro 2.6 code might have.

The WindowType Property

The FormSet WindowType property identifies the READ compatibility mode of converted forms. If forms are in READ compatibility mode, the WindowType property is either 2 (Read) or 3 (Read Modal), and the form set takes on the READ qualities of a 2.6 screen set. Execution stops when a DO FORM or SHOW command calls the form.

The WindowType properties that relate to 2.6 screen compatibility are only available with Functionally converted 2.6 screens. When screens are converted Visually or are created in Visual FoxPro, this WindowType property only relates to standard Visual FoxPro modeless and modal behavior and cannot be set to 2 and 3. The only time you will see form set WindowType properties with READ capabilities is in a Functionally converted form set.

Variable Scoping in Load Events

In FoxPro 2.6 READ compatibility mode, variables created in the Load event of a form set with WindowType set to 2 or 3 are scoped to the form set and visible to the entire form set, its forms, and its controls. You can control the visibility of variables created in other form set events or methods by using the PRIVATE, PUBLIC, or LOCAL commands.

Environmental settings are automatically defined in the form set Load event and the current record pointers are saved in public variables during the form set Unload event. The data environment of the form is updated with all appropriate FoxPro 2.6 view environment objects, such as the table aliases, index orders, and relationships. The FoxPro 2.6 generator directives for automatically opening and closing the tables are moved to the AutoOpenTables and AutoCloseTables properties in the DataEnvironment object.

Mapping

FoxPro 2.6 screen feature	Visual FoxPro feature
Screen set	Form set
Screen	Form contained in a form set
READ level	Page contained in a page frame
READ screen mode	WindowType property = 2
READ MODAL screen mode	WindowType property = 3

 

FoxPro 2.6 screen snippet	Visual FoxPro property or event
Form Level
Open Files	FormSet.AutoOpenDE
Close Files	FormSet.AutoCloseDE
Window Name	FormSet.WinName.Name
Window Title	FormSet.WinName.Caption
Width	FormSet.WinName.Width
Height	FormSet.WinName.Height
Left	FormSet.WinName.Left
Top	FormSet.WinName.Top
Center	FormSet.WinName.AutoCenter
Border	FormSet.WinName.BorderStyle
Moveable	FormSet.WinName.Moveable
Close	FormSet.WinName.Closeable
Icon	FormSet.WinName.Icon
HalfHeight Title Bar	FormSet.WinName.HalfHeightCaption
Color	FormSet.WinName.BackColor
Wallpaper	FormSet.WinName.Picture
Minimize	FormSet.WinName.MinButton
Font	FormSet.WinName.FontName/FontSize,Fontbold
Environment	FormSet.WinName.DataEnvironment




---

Modifying 2.6 Reports

You must convert FoxPro 2.6 reports (.frx files) to Visual FoxPro reports in order to access files in the Report Designer and to add Visual FoxPro functionality.

To convert a FoxPro 2.6 report, use the MODIFY REPORT command. The conversion process performs these steps:

1. Adds a user field to the .frx file.


2. Changes any Memo fields from 10 bytes to 4 bytes.


3. Adds records to support the data environment of the report. FoxPro


4. 2.6 environment records convert to data environment records.


5. Sets the AutoOpenTables and AutoCloseTables properties of the Data Environment and the Destroy event of the new report for backward compatibility with the ENVIRONMENT clause of the FoxPro 2.6 REPORT command.

If the FoxPro 2.6 report was created without an ENVIRONMENT clause, the AutoOpenTables and AutoCloseTables properties of the converted report are set to false (.F.).

If the FoxPro 2.6 report was created with an ENVIRONMENT clause, the AutoOpenTables and AutoCloseTables properties of the converted report are set to true (.T.). The Destroy event of the converted report contains the following code:

THIS.OpenTables && Opens all the tables
THIS.Init && Runs the Init code of the converted report's


                                              && DataEnvironment

After converting a report, Visual FoxPro opens the Report Designer so you can add Visual FoxPro functionality to the converted report.

Gotchas with Forms

After you convert a FoxPro 2.6 screen (.scx) file, you should check for the following conditions:

· READ statements with both a MODAL and DEACTIVATE clause. Visual FoxPro processes both these clauses.

· Conflicting control, object, form, and variable names.

· Controls under shapes. In FoxPro 2.6, the positions of shapes has no effect on other controls. In converted FoxPro 2.6 screens, shapes are behind all other controls and invisible buttons are always on top of all other controls.

· UDFs and other code that might be superseded by new Visual FoxPro commands or functions. HOME() and OLDVAL() are new Visual FoxPro built-in functions. Check the Help file for further information.

· Macro substitutions. Replace macro substitutions in the Properties window with variable assignments. For example, a PushButton prompt in FoxPro 2.6 Screen Builder that contains &lcprompt is converted to ="&lcprompt" and must be changed to =lcprompt.

· In the setup code of a FoxPro 2.6 form you can prevent the creation of the WINDOW by issuing a RETURN.

IF somecriteria
	RETURN
ENDIF


In Visual FoxPro you must issue a RETURN .F. in order to cancel the instantiation of the form.


IF somecriteria 
	RETURN .F.
ENDIF

· Clauses in snippets to "fool" Genscrn.prg won't convert. This includes code generated by Genscrnx.prg, a freeware code generator for FoxPro 2.6 screens. It is recommended that screens taking advantage of such code be recreated in Visual FoxPro.

· Generator directives. The code generated by the Converter is included in the new form during the conversion, but the code becomes static, so changes in the #INCLUDE file will not be reflected in the new Visual FoxPro form. In other words, in FoxPro 2.6, when you had a file to #INSERT, any changes you made to that file would be reflected each time you regenerated the .spr. In Visual FoxPro 5.0, the file is converted only once. Subsequent changes to the file won't be reflected in the form. You have to make the changes directly in the load snippet. During the conversion, the #INSERT code is copied into the method for the snippet. The #INCLUDE cannot contain procedural code. It can only contain precompiler directives (#DEFINEs, #Ifs, etc). Be sure to copy #DEFINEs into an .H file and use the #INCLUDE directive to specify the .H. file.

Post conversion - extending a functionally converted form

You can completely change converted FoxPro 2.6 screens to the Visual FoxPro event model:

· Change the WindowType property from 2 (Read) to 0 (Modeless), or from 3 (Read Modal) to 1 (Modal).

Note When you make this change, the READ compatibility properties and events are no longer available and the WindowType setting cannot be changed back.

· If you have a single form, move FormSet event code to the matching or appropriate form events and remove the FormSet.

· Move code from the READ-compatibility events to the form events and methods that are now available, taking event firing sequences into account

· Change CLEAR READ to RELEASE THISFORMSET or RELEASE THISFORM.

· Change SHOW GET to <object>.Refresh.

· Change SHOW GETS to THISFORM.Refresh or THISFORMSET.Refresh.

· Change SHOW GET for List and Combo boxes to <object>.Requery.

· Move READ SHOW and READ WHEN to the form set Load event.

· Move READ ACTIVATE and READ DEACTIVATE to the form set Activate and Deactivate events.

· Move READ VALID to the QueryUnload event.

· Use copy and paste to move all objects from the page to the form itself.

· Remove extraneous page and page frame controls.

· Move parameters from the screen Load event to the Init event of the form.

· Adjust scoping of variables in events or methods, which are private by default, by using the PUBLIC, PRIVATE, or LOCAL commands or by adding properties to the form.

1 Change form-level variables to user-defined form properties.
2 Create form methods for form-specific procedures and functions.
3 Make all data sessions private. (See the DevCon session on buffering.)

To run the form directly, move code from the generated .spr file to appropriate methods in the form so you can run it with the DO FORM command.

---

Moving a Foundation READ into Visual FoxPro

In FoxPro 2.6, the foundation READ was used to emulate event-driven programming by providing an event loop and handler. In Visual FoxPro, you can take advantage of the native event loop by converting your foundation READs.

Replace any foundation READ in the main program with a READ EVENTS command. For example, include a READ EVENTS command in a .prg program that runs your main form or form set.

Place a CLEAR EVENTS command in the form, menu, or program event that ends the program. For example, assign a CLEAR EVENTS command to the Exit menu item.

You may have code that closes things (tables, windows, etc.) neatly. When you move into the new event model you won't need any of this code, because Visual FoxPro handles it all for you.

Also, check the settings of the form set WindowType property for your converted screens. In FoxPro 2.6, you coordinated screens through READ and READ MODAL statements. These statements are converted to the WindowType property when you convert your files. For backward compatibility, the property is automatically set to 2 or 3, depending on the READ mode of the original screen. To enable full event model functionality once you've converted foundation READs, change the READ compatibility mode of screens, remove extra pages and page frames, and change form methods.

---

Other Gotchas

User Interface

In Visual FoxPro, the TAB key navigates between controls. To move through options in a list box, use the arrow keys.

Some hot keys have changed to conform with the Windows 95 user interface guidelines.

FoxPro 2.6	Visual FoxPro	Definition or difference
n/a	CTRL+N	Create a new file
CTRL+N	CTRL+O	Add a record to a Browse window
CTRL+O	CTRL+E	DO program from within edit window

Language

FoxPro 2.6 ignores anything longer than 10 characters, but Visual FoxPro supports and recognizes the longer variable names. If you took advantage of this FoxPro 2.6 "feature", you need to modify your code. To see the difference, run this code in FoxPro 2.6 and then in Visual FoxPro:

clear

store "hello" to clcustomer1

?clcustomer1

?clcustomer

store "goodbye" to clcustomer2

?clcustomer2

?clcustomer

Visual FoxPro also supports longer file names. In FoxPro 2.6 you could have a table called Mynewtab.dbf and this command would work fine: USE MYNEWTABLE. In Visual FoxPro 5.0, this command used on the same file will generate a "file does not exist" error.

There are now 32767 work areas! This affects code that loops through work areas (up to 225). Use AUSED() instead. Note that this affects SELECT(1). See what you get by issuing this command in FoxPro 2.6 and Visual FoxPro 5.0.

---

Table and Database Differences

Visual FoxPro distinguishes between tables and databases. Although FoxPro 2.6 tables are fully functional in Visual FoxPro, if you modify the table structure of FoxPro tables to take advantage of any of the new Visual FoxPro 5.0 table features like acceptance of null values, they are saved as Visual FoxPro tables. Note that if you merely change things like field size, field names, or only add or delete fields the table is maintained as a FoxPro 2.6 file.

FoxPro 2.6 table structure feature or functionality	Visual FoxPro structure feature or functionality
Character field with NOCPTRANS characteristic	Character (BINARY) field type
Date fields	Date data type, DateTime data type
General field size	Now 4 bytes
Memo field size	Now 4 bytes
Memo field with NOCPTRANS characteristic	Memo (BINARY) field type
Numeric fields	Currency data type, Double field type, Float field type, Integer field type, or Numeric data type
OLE data in a General field	OLE Bound control

The structure of Visual FoxPro project (.pjx), screen (.scx), report (.frx), and label (.lbx) files differ from the structure of FoxPro 2.6 files. For details on the structure of Visual FoxPro table files created in the Project Manager, Form Designer, Report Designer, and Label Designer, see Table Structures of Table Files. The filespec directory contains reports you can print out that have specific details of the structures of Visual FoxPro, as well as FoxPro 2.x, tables.

Null Values

Visual FoxPro tables can accept null values. To prevent errors generated by attempts to store null values to FoxPro 2.6 variables or to Visual FoxPro controls, initialize variables or arrays. To prevent users from attempting to store null values to tables, you can disable the NULL entry key combination by using the following statement:

ON KEY LABEL CTRL+0 *




Views in Visual FoxPro

Visual FoxPro allows you to use views as you would tables or queries. If you build a view in Visual FoxPro without qualifying the table name to a database, you'll get an error when you try to modify the view in the View Designer. To ensure that you can use or modify views in all versions of Visual FoxPro, use CREATE SQL VIEW with the FROM clause as in the following example:

FROM testdata!products        && testdata is the database name

				&& products is the table name

When you specify the source this way, Visual FoxPro searches for the table both in the open database list, including the current and any non-current databases, and in the default search path for the table.

Converting Tables

Visual FoxPro does not change the structure of FoxPro tables unless you add the table to a database or add a new data type or enable acceptance of null values. Once you change the structure of a table by adding a new data type such as DateTime, or by enabling null values in a field, Visual FoxPro modifies the table file structure, making the file unrecognizable to FoxPro 2.6.

You can create a FoxPro 2.6 table from a Visual FoxPro table by using the COPY TO command with the TYPE clause and the FOX2X keyword, as in the following example:

* A Visual FoxPro table

USE vfptable.dbf

* Creates a FoxPro 2.6 table

COPY TO fp26tabl.dbf TYPE FOX2X

To copy a FoxPro 2.6 table structure from a Visual FoxPro table, use COPY TO and the NEXT clause, as in the following example.

* Creates an empty FoxPro 2.6 table

COPY TO fp26tabl.dbf NEXT 0 TYPE FOX2X

Visual FoxPro changes all null values in NULL-enabled fields to either 0 or blank, and creates a structure recognized by FoxPro 2.6. Visual FoxPro also converts Integer, Double, and Currency types back to Numeric, and changes DateTime to Date type. Approach 3 Total rewrite

Well, not exactly total. You can, of course, keep the data structures and business rules you have already developed. But you will want to take the time to redesign your application to take advantage of OOP structure and functionality. This is the most costly (and time consuming) approach, but it is also the most powerful and flexible. This approach allows you to take advantage of all the new features of Visual FoxPro 5.0. In addition, you will find that you can eliminate hundreds (thousands?) of lines of code because Visual FoxPro 5.0 has built-in functionality that you once had to code yourself.

Many developers claim unequivocally that a total rewrite is the way to go, especially with applications that are simple. With the new features of Visual FoxPro 5.0 you will find elegant solutions to problems you needed "kludges" for in FoxPro 2.6. You will begin to develop class libraries to use again and again in future application development.

The best investment of time and resources will be in the design phase of your new application. Learn OOP techniques and learn how they work in Visual FoxPro.

---

Take advantage of one of Visual FoxPro 5.0's coolest new features to use information from your 2.6 application

Visual FoxPro 5.0's ability to be a custom OLE Server will enable you to use your 2.6 application to provide information to another application.

The Laser sample that ships with FoxPro 2.6 is a laser disk library manager program. The main program is Laser.spr. To turn this into an OLE object callable from Visual Basic or Microsoft Excel, create a new project in a new main program:

ox = create("laser")

define class laser as custom olepublic

	proc init

		cd d:\fpw26\sample\laser	&& change dir to the right place

		set path to data

		this.application.visible = .t.	&& make us visible.

	proc doit

		do laser.spr

enddefine

Add the new Laser.spr to the project. You'll need to manually add any supporting files, like .bmp files, to the project. Then, you can try:

OX = Createobject("laser.laser")

and then:

OX.Doit.

The laser application is now running as an OLE Automation server! If you modify the Laser.spr program so that it doesn't close the LASER table when the READ is finished, then you can query what laser disc title was chosen:

?ox.application.eval("title")

---

Summary

If your application is working well in 2.6, you don't need to add features to your application, and your investment in time and cost of upgrading, you might wish to stay with FoxPro 2.6. However, you will want to move your applications into Visual FoxPro so that you can begin to take advantage of all its new features and functionality. In addition to the features that came with Visual FoxPro 3.0 (OOP, database features, etc.). Visual FoxPro 5.0 adds improved performance, the new development environment, and new database features of Visual FoxPro 5.0.

Converting Visual FoxPro 3.0 Source Control Projects to Visual FoxPro 5.0

This article explains how you can convert a Visual FoxPro 3.0 project that is under Source Code Control (SCC) to a Visual FoxPro 5.0 project while maintaining it under Source Code Control.

Information

Use the following steps to convert a Visual FoxPro 3.0 project that is under Source Code
Control:

1.Back up the Source Code Control provider database and any files for the Visual FoxPro 3.0 project that you are converting.

2.Run the SCC provider and logon.

3.Select the project to be converted--for example, a project named "SCCTST" under the Root Project ($). Then click Check Out on the Visual SourceSafe menu.

4.In the Check Out dialog box, make sure that the "TO" text box contains the Path and the name of the working directory, for example "C:\Wdscctst."

5.Click Recursive and then OK.

6.Once the Check Out process is completed, run Visual FoxPro 5.0.

7.Click Options on the Visual FoxPro 5.0 Tools menu, and in the Projects tab ensure that the SCC Provider you want to use is selected as the "Active Source Control Provider."

8.MODIFY the Visual FoxPro 3.0 project(SCCTST)that was checked out in Step 6 to the working directory (C:\Wdscctst).

9.When the "Visual FoxPro Converter" dialog box comes up, select any of the choices you want to. It is recommended that you use the default choices. Then click OK.

10.When the "Project has been moved" message comes up, click Yes. After the Project and its components are converted, Close and Save it.

11.Switch to the SCC provider. Select the Project (SCCTST) and click Check In on the Visual SourceSafe menu.

12.In the Check In dialog box, click Recursive and then OK.

13.Check out the files again from the SCC provider, using steps 3, 4, and 5 above.

14.After the Check Out process is completed, switch to Visual FoxPro 5.0.

15.Modify the project SCCTST that was checked out to the working directory Wdscctst.

16.Click Add Project to Source Control on the Project menu. When prompted, logon to the SCC provider.

17.In the Add to Visual SourceSafe Project dialog box, enter the name of the project "SCCTST" in the "Project:" text box. Ensure that this name is exactly the same as the one displayed for the project in the Project Tree Structure under the "$/".

18.In the Project Tree Structure under "$/", select the project that is the parent of the project being converted. For example, if project "SCCTST" is a Sub-Project of the "Root Project" ($\SCCTST), then select the Root Project ($), and if SCCTST is a sub-project of "PSCCTST," which in turn is a sub-project of "$" $\PSCCTST\SCCTST), then select "PSCCTST."

19.Click OK. When the "Project Metafile created by Visual FoxPro" message is displayed click OK again.

20.When the Add Files to Source Control dialog box comes up, click Select All and OK.

21.The "File is already controlled. Delete the local copy and get the latest version" dialog box appears several times. Click YES each time.

22.When the "Do you want to update the project list" dialog box is displayed, click Yes.

23.When the "File checked in from Visual FoxPro" message appears, click OK.

NOTE:The Form (.scx), Label (.lpx), Menu (,mnx), Report (.frx), and Class Library(.vcx) files are in binary format and most SCC providers are not capable of maintaining the History/Version information for such files.

To allow the SCC provider to keep track of the changes to the binary files, Visual FoxPro 5.0 allows you to create files that are a Text representation of these binary files. The name of the text file is the same as the binary file except that the last letter of the extension is an "A" instead of an "X." For example *.SCA, *.LBA, *.MNA, *.FRA, and *.VCA for *.SCX, *.LBX, *.MNX, *.FRX, and *.VCX files, respectively.

The text files are not added to the Project Manager so are not listed within the Project
manager. These files are checked in and out automatically by Visual FoxPro 5.0 whenever their respective binary files are checked in and out.

1.To create text files for the binary files run Scctext.prg, installed to the Visual FoxPro 5.0 directory by default, against each of the files as follows:

DO SCCTEXT.PRG WITH "WDSCCTST\Forms\FormName.SCX"
DO SCCTEXT.PRG WITH "WDSCCTST\Labels\LabelName.LBX"
DO SCCTEXT.PRG WITH "WDSCCTST\Menus\MenuName.MNX"
DO SCCTEXT.PRG WITH "WDSCCTST\Reports\ReportName.FRX"
DO SCCTEXT.PRG WITH "WDSCCTST\Classes\ClassName.VCX"

NOTE: The Text files are created in the same directory as each of the respective Binary files. For example FormName.SCA goes to the "WDSCCTST\Forms\" directory, ClassName.VCX to "WDSCCTST\Classes\" directory, and so on.

2.Once all the .sca, .lba, .mna, .fra, and .vca files are created, click Source Control, and then Check In from the Visual FoxPro 5.0 Project menu.

3.When the Check In dialog box appears, click Select All and then OK.

4.After the Check In process started with the previous step has completed, note that the text files ("*.??A") are not added to Source Control at this time. These files have to be added individually from the SCC provider.

5.Switch to the SCC provider and Check In each of the "*.??A" files into the specific folders of the SCC project (SCCTST). For example, *.sca files go to the Forms folder under "$\Scctst\," the *.fra files go to the eports folder, and so on. Once this is finished, the text files are checked out or checked in automatically whenever their respective binary files are checked out/in from within Visual FoxPro 5.0 using the SCC Integration functionality.


Now you should be able to use the Project under Visual FoxPro 5.0 while retaining its Source Code Control functionality. Whenever you open the project (C:\Wdscctst\Scctst), Visual FoxPro 5.0 automatically knows that it is under Source Control and provides the required functionality.


NOTE: Once the Project has been added to Source Control under Visual FoxPro 5.0, it is
advised that the SCC operations should be performed from within Visual FoxPro using the
SCC Integration functionality.

NOTE: The above steps were tested with Microsoft Visual SourceSafe and are specific to
it. For Source Code Control providers other than Microsoft Visual SourceSafe, you may
need to modify the above steps or may have to do additional steps.

Converting Visual Basic for Application to FoxPro for OLE Automation

Introduction
General Notes
Object Variables
Directory/File Management Statements


Introduction

In order to perform OLE Automation with an application that uses Visual Basic for Applications (VBA), it is important to understand how to convert the VBA syntax for each command or function into a syntax that may be used in Visual FoxPro. Below is a list of a few of the most common Visual Basic for Applications (VBA) commands that may be used to perform OLE Automation from Visual FoxPro to Microsoft Excel or Microsoft Word along with the appropriate syntax for use in Visual FoxPro.

Since this list is very limited, it may be helpful to understand some of the points of converting VBA to FoxPro:

1. Use parentheses to surround the list of parameters.

2. Do not use Named parameters. Instead, just pass the value of the parameter in its specified position in the list.

3. You may use FoxPro variables and fields as parameters just as you would in FoxPro commands, as long as they are of the correct type.

4. If you are having problems getting a statement or method to work, make
sure that it works as written from within a module of the application (Microsoft Excel or Microsoft Word). If it is available, you may also want to try the statement from Visual Basic.

For a description of the methods and statements listed, along with information about the use of specific parameters, please see the respective Visual Basic Reference file for Microsoft Word or Microsoft Excel.

---

General Notes

Variables and parameters are prefixed by a single character indicating the type of the variable or parameter as follows:

• c Character
• n Numeric
• o Object
• l Logical

Some portions of certain commands may be optional. These portions are enclosed by brackets [].

VBA has many built-in constants that may be used. However, FoxPro does not know the values of these constants. To use them in FoxPro, you need to define them as constants in the scope of your FoxPro program or form, or replace them with their appropriate values.

---

Object Variables

oWord is the variable used to reference Microsoft WordBasic objects, created with the following command:

   oWord = CREATEOBJECT("Word.Basic")

oXL is the variable used to reference Microsoft Excel application objects, created with the following command:

   oXL = CREATEOBJECT("Excel.Application")

oXLSheet is the variable used to reference Microsoft Excel worksheet objects, created with one of the following command:

   oXLSheet = CREATEOBJECT("Excel.Sheet")

   -or-

   oXLSheet = oXL.ActiveSheet

oXLBooks is the variable used to reference Microsoft Excel Workbooks Collection objects, created with the following command:

   oXLBooks = oXL.Workbooks

oXLWkBook is the variable used to reference Microsoft Excel workbook objects, created with the following command:

   oXLWkBook = oXL.ActiveWorkBook

---

Directory/File Management Statements

Add Method (Microsoft Excel)

   Syntax:

   oXLBooks.Add([cTemplate])
   oXLSheet.Add([cBefore [, cAfter [,nCount [, nType]]]])
   oXLSheet.Add([oBefore [, oAfter [,nCount [, nType]]]])

Cells Method (Microsoft Excel)

   Syntax:

   oXL.Cells([nRowIndex [, nColumnIndex]])
   oXLSheet.Cells([nRowIndex [, nColumnIndex]])

ChDir Method (Microsoft Word)

   Syntax:

   oWord.ChDir(cPath)

   Example:

   oWord.ChDir("C:\MY DOCUMENTS")

Close Method (Microsoft Excel)

   Syntax:

   oXLBooks.Close()
   oXLWkBook.Close([lSaveChanges [, cFileName [, lRouteWorkbook]]])

FileClose Method (Microsoft Word)

   Syntax:

   oWord.FileClose([nSave])

FileCloseAll Method (Microsoft Word)

   Syntax:

   oWord.FileCloseAll([nSave])

FileNew Method (Microsoft Word)

   Syntax:

   oWord.FileNew([cTemplate [, nNewTemplate]])

   Example:

   oWord.FileNew("C:\MY DOCUMENTS\MYTEMPLATE.DOT")

FileNewDefault Method (Microsoft Word)

   Syntax:

   oWord.FileNewDefault()

FileOpen Method (Microsoft Word)

   Syntax:

   oWord.FileOpen(cName [, nConfirmConversions [, nReadOnly ;
      [, nAddToMru [, cPasswordDoc [, cPasswordDot [, nRevert ;
      [, cWritePasswordDoc [, cWritePasswordDot]]]]]]]])

   Example:

   oWord.FileOpen("C:\MY DOCUMENTS\MYWORD.DOC")

Open Method (Microsoft Excel)

   Syntax:

   oXLBooks.Open(cFileName [, nUpdateLinks [, lReadOnly [, nFormat ;
      [, cPassword [, cWriteResPassword [, lIgnoreReadOnlyRecommended ;
      [, nOrigin [, cDelimiter [, lEditable [, lNotify ;
      [, nConverter]]]]]]]]]]])

   Example:

   oXLBooks.Open("C:\MY DOCUMENTS\MYSHEET.XLS")

Value Property (Microsoft Excel)

   Syntax:

   object.Value = NewValue

   Example:

   oXL.ActiveWindow.ActiveCell.Value = "Hello"