Creating Applications with the Application Wizard
J. Michael Pope, Microsoft Corporation

Introduction

The Microsoft® Visual FoxPro™ 5.0 Application Wizard is a tool for getting applications (projects) up and running quickly. The wizard can create a project directory structure; include database elements from an existing database or a database template; include forms, reports and other documents; create a custom menu; include a main program to launch the application; and more.

You could do all of these tasks without the help of the Application Wizard. However, the wizard can accomplish the tasks very quickly and with almost no effort on your part. Also, the wizard makes sure that all the components and linkages that you specify are in place and are correct. Finally, the wizard makes available an Application Wizard class (cApplication), two custom forms, and a class library that can make it easier to manage and enhance the application that the wizard creates. Even if you are an experienced developer, you will find that you can use the Application Wizard as a prototyping tool to pull together sample applications quickly and easily.

When you have finished running the Application Wizard, you have a complete application; one that you can compile and run. In most cases, of course, you will probably want to do further customizing. You can add more components — such as custom code — to the application, or you can customize the components that the wizard has created. For example, you will want to add content to the "About" dialog box. But the framework and content of your application will be in place and ready to work with.

The purpose of this document is to provide you with more in-depth information about the Application Wizard, including:

It is assumed that you already know how to run the wizard, and have a general understanding of how to work with the Visual FoxPro Project Manager, how to create and manage forms and menus, and how the Visual FoxPro object model works.

What Did It Do? What the Application Wizard Creates

The basic function of the Application Wizard is to create a new project and populate it with the data, forms, reports, menus, programs, and class libraries that you need. When you run the wizard, you have the choice of creating either a framework or complete application. A framework creates a project (.PJX) file and directory structure, and then adds some default elements such as forms. If you created a complete application, the framework is fleshed out with data files and additional documents that you specify.

Default Objects

Whether you chose to create a framework or complete application, the Application Wizard creates the following elements.

Directories

If you specified the Create Project Directory Structure option in Step 1 of the Application Wizard, the wizard creates a directory structure with separate directories for different project elements: FORMS for forms, DATA for data files, LIBS for class libraries, and so on. You can customize what names the wizard assigns to these directories. For details, see "Customizing Directory Names" later in this document.

Class Libraries

The wizard includes one class library: a parent class library for the application class (APPWIZ.VCX). When the wizard runs, it also creates an application-specific library (project.VCX). The project.VCX file is created in the application's LIBS directory, and contains the class cApplication that is the heart of the application.

The APPWIZ.VCX library contains the parent objects for the QuickStart form (wzQuickStartForm), the About form (wzAboutForm), and for the application object itself (wzApplication). It is important to understand that methods and properties for these objects are defined in the parent classes. For example, although the list box in the QuickStart form contains an Init method, there is no code there; the code appears in the Init method of the list box in the QuickStart form's parent, wzQuickStartForm, in the AppWiz library. Similarly, the application object's Show method is defined not in the cApplication class, but in its parent, wzApplication. For more details about the application class cApplication, see "About the Application Class" later in this document.

Menu

The wizard creates a menu (project.MNX) in the application's MENUS directory to be used as your application's main menu. The menu contains many of the same options as the main Visual FoxPro menu, excluding commands that are not available at run time. In addition, it can contain the following submenus, depending on whether you excluded certain menus and on what documents are available in the application:
 
File Contains two commands:
Close Closes the current form by calling the application class's ReleaseForm method.
Exit Quits the application by calling the application class's Release method.
Forms Lists all the forms that were included when the Application Wizard created the application. The forms are run by calling the application class's DoForm method.
Reports Lists all the reports and labels that were included when the Application Wizard created the application. The forms are run by calling the application class's DoReport method; labels are run by calling the application class's DoLabel method.
Help Displays the About dialog box.

Forms

The wizard includes two forms by default: a QuickStart form (QCKSTART.SCX) and an About form (ABOUT.SCX). The QuickStart form displays a list of the application's forms and allows the user to display any of them by double-clicking their names. Users can close the QuickStart form by clicking Close, pressing ESC, or pressing CTRL+W. The list of forms displayed in the QuickStart form is built dynamically. When the form is displayed, the Init method of its list box (actually, of its parent object's) scans the application's startup menu and picks out the names of forms that appear there. You can therefore control what forms appear in the QuickStart form by adding or removing forms from the application's startup menu.

The About form is called from the application's Help menu and is initially blank. You should edit this form and add information such as the application name and version number, your company name and contact information, a copyright statement, and so on.

Program

By default, the wizard creates a single program in the application (program.PRG), which is intended to serve as the application's main file. For details about how the main program works, see "What Happens When you Run the Application" later in this document. You can modify the program created by the Application Wizard; for example, you can add initialization or other code to it. You can also change what the Application Wizard puts into the main program when it is generated. For details, see "Modifying the Main Program Template" later in this document.

Text Files

The wizard builds two text files. The first is project.H, which contains an #INCLUDE command to include FOXPRO.H. This file is stored in the application's INCLUDE directory. The second text file is APPWIZ.TXT, which contains documentation on how to customize the Application Wizard. It is included by reference from the Visual FoxPro WIZARDS directory.

Bitmaps

The wizard also includes bitmaps required by forms in your application. As a minimum, the application includes a reference to FOXQSTRT.BMP, a bitmap used as a tiled background in the QuickStart form. You will probably want to replace this bitmap with another. If you have included forms in your application that require bitmaps, such as button graphics, those bitmaps are included as well.

If You Use a Database Template

If you specified a database template in Step 2 of the Application Wizard, the wizard includes all the elements noted earlier, such as the QuickStart and About forms, the main program (project.PRG), and so on. The wizard also adds data, forms, reports, and other application-specific elements to your new project.

Data Files and Indexes

If the database template includes data tables, then the database container (.DBC) file, tables, and associated indexes are copied to the DATA directory of your new project. If the tables in the template include data, the data is copied as well. This makes it easy for you to prototype and test your new application. However, be sure to remove the sample data before putting the application into production.

Documents, Programs, and Class Libraries

If you did not exclude them in Step 3 of the Application Wizard, the forms, reports, programs, and class libraries from the template are copied to your new project directory structure. For example, if your database template contains a form called CONTACT.SCX, and if you do not exclude this form when running the Application Wizard, the wizard copies the form to the directory myproj\FORMS\CONTACT.SCX.

Objects Included If You Used an Existing Database When Running the Wizard

If you specified that the Application Wizard should include an existing database when creating the new project, then the forms, reports, other documents, and class libraries are all included in the project by reference.

The advantage of including documents, programs, and libraries by reference is that you avoid duplicating them. This makes it easier to maintain your documents, because a change made in one form (for example) can be propagated to all the projects that use the form. If you want to create application-specific versions of these forms or other elements, you can subclass the element and modify that. Or you can open the document or library, and then save an application-specific version of it in the project directory for your application. You must be careful when referencing documents and libraries from within your application because they are on a different path than the project directory. Do not use absolute path references; instead, use a relative path.

The same holds true for tables. Like documents, they are included by reference in order to avoid making copies of files — both for ease of maintenance, and in the case of data tables, to avoid data duplication.

When working with data that is referenced from another location, it is wise to use intelligent path references. Unlike documents and libraries, the data tables will not be included in your .APP or .EXE file when you compile the application, so it is critical that your code refer to the data tables using a path reference that will not fail if the data tables are packaged for distribution.

What Next? Working with Applications Created by the Application Wizard

In theory, if you have finished with the Application Wizard and specified that you wanted a complete application, you are ready to run your application. That's true; you can compile and run the project as-is. If you are using the Application Wizard primarily to create a quick prototype, that might be all you need.

But if you are intending to create an application for distribution, you probably want to at least tweak the project to suit your needs. And, of course, if you used the Application Wizard to create only a framework, you still have to add your project elements — data, documents, and so forth — before the application is ready to go.

To help you modify a generated application, this section provides information on these topics:

Understanding How a Generated Application Works

To be able to modify an application created by the Application Wizard, you must first understand the architecture of a project created by the wizard. To do so, you should understand first what the application class is, and then study the application flow in a generated application — that is, what happens when you run the application.

About the Application Class

The heart of an application created with the Application Wizard is its application class. The application class is a container object used to manage the application by setting its environment, controlling the user interface, and shutting the application down cleanly. When you start the application, the main program instantiates the application object, then calls its methods to display forms, menus, and reports and to set the application's caption, icon, and so on.

The application object is available as the object cApplication in a class library named after your project. For example, if you named your application MyApp, the application object cApplication is in the library MYAPP.VCX, stored in the LIBS directory for your application.

The application object is subclassed from a parent object called wzApplication in the library APPWIZ.VCX, which is stored in the Visual FoxPro WIZARDS directory. In fact, the application-specific application object cApplication does not contain any of the code used to work with the application object. For example, although the cApplication object has a DoForm method, the method is blank. Instead, the cApplication object inherits its methods and properties from its parent object, wzApplication.
 

 
Using the cApplication class, which inherits its methods and properties from a parent class, has several advantages. First, it makes it easy to customize the application class individually for each application you create with the Application Wizard. For example, if you want to change how one specific application is initialized, you can change the Init method in the cApplication class for that application without affecting how other applications work. Second, you can change all your applications at once by customizing the parent class, wzApplication. For example, you can add a new method to the parent class, and then call it from all the applications created by the Application Wizard.

When the application's main program instantiates the application class, the program assigns the reference to the public variable goApp. You can therefore call any of its methods or set its properties using this syntax: 

goApp.Method( [parm1] )
goApp.Property = newValue
	-or-
cVar = goApp.Property

What Happens When You Run the Application

If you have used the Application Wizard to build a complete application, you have something that you can run immediately. The exact course of events when the application runs depends on what choices you made when you ran the Application Wizard. However, the following outline describes a typical application that relies on the Application Wizard defaults.

  1. The main program runs and accomplishes the following tasks:

  2. The application object's Show method takes over and accomplishes the following tasks:

While the application is running, it remains in the hands of the startup form and menu until the application object's Release method is called, which closes all open forms and stops event processing. At that point, control returns to the application's main program, which releases the application object and then restores the Visual FoxPro environment and menu.

Running the Application

A quick way to run your application is to select the application's main program (project.PRG) in the Project Manager, and then choose Run. When the main program runs, it displays the application's main menu and startup form. The Project Manager remains visible.

A more formal way to run the application is to compile it in the Project Manager. You can then run it as you would any Visual FoxPro application, using the DO command. For example, if you have created the application MyApp in the MYAPP directory, you can run the compiled version using this command: 

DO HOME() + "MYAPP\MYAPP.APP"

To quit the application and return to the Visual FoxPro development environment from an application, choose Exit from the File menu, or call the application object's Release method, which closes all open forms and performs an orderly shutdown. For example, you could use this command: 

goApp.Release()

Modifying the Application

After generating an application with the Application Wizard, you can modify it as you would any project, using the Project Manager to edit, add, and remove application elements. There are only a few techniques to note about integrating your changes into the generated application.

Managing Forms

Add new forms to your application using the Project Manager. If you want the forms to appear on the Forms menu, use the Menu Designer to edit the application's main menu (project.MNX), and then regenerate the menu. Putting a form on the Form menu also causes it to appear in the QuickStart form automatically.

You can display forms in your new app using the ordinary methods: for example, DO FORM plus the name of the form. However, you can also use the application object to display the form, which provides additional benefits, including the ability to cascade multiple instances of the form or to run the form without displaying it. To run the form, call the application object's DoForm method, specifying the name of the form to call: 

goApp.DoForm("About.SCX")

For details about calling the DoForm method, see the appendix to this document. To close a form, call the application object's ReleaseForm method. If more than one form is open, you can specify the form to close; the default is to close the currently active form: 

goApp.ReleaseForm("About.SCX")

To change the startup form, modify the application object's cStartupForm property in the application's main program. By default, the startup form is set to QCKSTART.SCX. For example, the last line in the following code sets the startup form: 

*-- Configure application object.
goApp.SetCaption("MyApp")
goApp.cStartupMenu="menus\myapp"
goApp.cStartupForm="forms\MyStart.scx"

Managing Reports, Labels, and Menus

You can add reports and labels the same way you add forms: using the Project Manager. As with forms, you can call an application object method to display the reports or labels: 

goApp.DoReport("report.FRX")
goApp.DoLabel("label.LBX")

Be sure to include path information if necessary. However, avoid absolute path names; instead, create relative path names based on the directory available using the HOME( ) function: 

goApp.DoLabel(HOME() + "MYAPP\MYAPP.LBX")

You can make changes to the application's startup menu by editing the project.MNX file. Remember to regenerate the menu before running the application, or your changes will not be reflected. (If you build the application, the menu is automatically regenerated.)

Changing the Application Icon

By default, the icon displayed by a generated application is the Visual FoxPro icon. You can change the icon by calling the application object's SetIcon method: 

goApp.SetIcon("MYAPP.ICO")

Modifying the Application Class

You can change the overall behavior of the application by modifying the application class itself. For example, you can change the initialization code in the application, or you can add or customize methods in the application class.

If you want to change the application class, modify the cApplication class in the project.VCX file. You'll see that there is no code in this class; the class is subclassed from the wzApplication class in the APPWIZ.VCX library. As a rule, if you are modifying the application class for only one application, you should not modify the parent class because changes made to the parent affect all sublcassed classs in all applications.

If you want to modify one of the methods defined for the application class, write the code in the method of the cApplication class. Then, if appropriate, use the DoDefault( ) function to call the corresponding method of the parent class. Be sure to provide for any parameters passed to the method when you write the code and when you call the parent method. For example, the following code illustrates how you might modify the DoForm method in the cApplication class: 

LPARAMETERS p1, p2, p3, p4
PUBLIC lPasswordOK
DO password_prompt
IF lPasswordOK THEN
	* now call the parent method
	DoDefault( p1, p2, p3, p4 )
ENDIF

You can add conditions to different phases of the application. For example, if your application requires a password, you can add a password prompt to the application at the point it starts. You have a variety of choices about where to add this type of processing. For example, you could modify the application's main program and add a prompt before the line that calls the application object's Show method, as in this example: 

*-- Add password prompt to application
goApp.DoForm("PSWRD.SCX")
IF lPasswordOK THEN
	goApp.Show()
ELSE
	RELEASE goApp
ENDIF

The application class also offers a hook, the BeforeReadEvents method, in which you can add code that is called before the application object starts event processing via its ReadEvents method. If you want to prevent the application from starting, you can set the application class's lReadEvent property (default = .T.). If this flag is set to .F., the READ EVENTS command isn't issued and the application stops before it starts.

Tip To customize the error handling for the application as a whole, modify the ErrorHandler( ) function in the application's main program.

Modifying How the Application Wizard Creates Applications

Much of the information that the Application Wizard uses to create the new application is available to you for modification. For example, you can change the contents of the project that the wizard creates, modify the main program, and change the names of the directories that the wizard creates. You can also modify existing database templates or add new ones.

The data files used by the Application Wizard are in the Visual FoxPro WIZARDS directory. All the files are named APPWIZ, but have different extensions depending on how they are used. The complete list appears in the following table.

Files used by the Application Wizard
Files Description
APPWIZ.DBF, APPWIZ.FPT Table of miscellaneous information, such as the names of directories to create and the names of available database templates. The table contains two fields, Type and Data1. Type contains a description of what the field is for, and Data1 is a memo field that contains the information required.
APPWIZ.H Template header file that contains an #INCLUDE statement to include FOXPRO.H. The header file is copied to the new project (marked excluded); it isn't referenced by any project files automatically.
APPWIZ.MNX, APPWIZ.MNT Template for main menu.
APPWIZ.PJX, APPWIZ.PJT Template for project file.
APPWIZ.VCX, APPWIZ.VCT Class library containing all application framework classes.

You can modify the information in these tables as you would any Visual FoxPro table. For example, to modify the menu created by the Application Wizard, open APPWIZ.MNX in the Menu Designer, and then make your changes. The next time you create an application using the wizard, the startup menu for the new application will reflect the changes you've made.

Important Before you make changes to the files in the WIZARDS directory, be sure to make backups so that if you inadvertently make a change that breaks the Application Wizard, you can recover. After you make your changes, make another, separate backup. If you ever reinstall Visual FoxPro, the entire WIZARDS directory can be overwritten. In this case, your second backup will allow you to preserve your customizations.

Modifying the Main Program Template

If you want to modify how the application's main program is created, you can change the template that the Application Wizard uses when creating the program. The template is stored in the APPWIZ.DBF table; look for the record where the value of the Type field is "STARTUP PROGRAM."

The template is stored in the memo field called Data1; this field contains the entire startup program. Most of the program is copied intact from the memo field into the new project. The wizard modifies only the lines surrounded by asterisks and brackets, such as *<PATH>*, by substituting information you enter while running the wizard. You cannot change the number of names of these placeholders, nor can you specify how the wizard should fill in these placeholder lines. However, you can change any other lines in the program.

Customizing Directory Names

You can change the names of the directories that the Application Wizard creates when it creates a project directory structure. To do so, open the APPWIZ.DBF file in the Visual FoxPro WIZARDS directory. When you browse the file, you'll see a set of records that contain the word "DIRECTORY" in the TYPE field. Each of these records represents a directory that the wizard will create. To specify the name of the directory, edit the corresponding Data1 field and enter the new name for the directory. For example, by default, the Application Wizard creates a directory called FORMS for the project's forms. To change the name of this directory, edit the record with "FORMS DIRECTORY" in the Type field, and assign a name such as MyForms.

Note: You can't add to the directories that the wizard creates. However, you can remove a directory entry from the APPWIZ.DBF file. If you do, the wizard doesn't create that directory, and places the files for that directory into the project's root directory.

Changing or Adding Database Templates

If you want to use an existing database template but it doesn't quite suit your needs, you can edit it the way you would any Visual FoxPro application. The templates used by the Application Wizards are stored in the Visual FoxPro WIZARDS\TEMPLATE\template directory, where template is the name of the template. Beneath this directory are the directories that actually contain the data used by the wizard. For example, the following tree illustrates the layout of the directories for two templates, Contact and Books.
 

 
To change the template, find the element you want to change — for example, the form CONTACTS.SCX in the CONTACT\FORMS directory — and use the appropriate editor to make your modifications.

You can also add entirely new templates, which is useful if you have an existing application that's a good model for future applications. To create a new template, create a directory structure for the template according to the model illustrated above. You must create the directories exactly as illustrated (DATA, FORMS, GRAPHICS, INCLUDE, HELP, LIBS, MENUS, PROGS, and REPORTS) and place the appropriate data in each. Then edit the APPWIZ.DBF file, and add a new record. In the Type field, enter the word "TEMPLATE," which tags the record as a template identifier. In the Data1 field for the new record, enter the name of the template, which must match the name of the new tree structure you created. For example, to create a new template called PHOTOS, enter TEMPLATE in field 1, and Photos in the first line of the memo field called Data1.

Note: Be sure that you include all the files required for the elements in your application. For example, if you generated a form using the Form Wizard, the form uses objects derived from the WIZSTYLE.VCX library.

Specifying Default Properties for a New Template

You can provide additional information about your new template by creating a template-specific data file that specifies default properties for individual files in your template. Create a table with two fields: Name and Properties. These can be either character or memo fields. Then save the table in the root directory for your template. For example, if you create a template called Photo, the root directory for the template might be the Visual FoxPro WIZARDS\TEMPLATE\PHOTOS directory, and your custom table could be WIZARDS\TEMPLATE\PHOTOS\PHOTOS.DBF. In the Name field, enter the name of the file for which you want to set a property. For example, to set default properties for a form, enter the .SCX file name for the form in the Name field. Then, in the Properties field, enter the name of a property, and if appropriate, its setting. The following table lists the properties you can enter into the Property field.
 
Property Name Description
menucaption Overrides the menu caption generated by searching the .SCX, .FRX, or .LBX file. For example, to set the menu caption for a form to "Invoice," enter the following: menucaption=Invoice
NoMenu Specifies that the file in the Name field will be excluded from the generated menu.
NoMultipleInstances Specifies that only one instance of the form (.SCX file) in the Name field can be loaded.
NoShow Specifies that the form (.SCX file) in the Name field is not shown when instantiated.
NoPreview Specifies that the report (.FRX file) or label (.LBX file) in the Name field is sent directly to the printer instead of being displayed in preview mode.

For example, imagine that the PHOTO template contains a form called Frames for entering information about individual negatives, and that you want users to be able to display only one instance of this form at a time. In the PHOTO.DBF file, enter FRAMES.SCX in the Name field, and NoMultipleInstance in the Properties field.

After you have created the template-specific table and filled in the file name and properties, you have one step left. To make sure the Application Wizard finds the template-specific table, you must enter the table name in the APPWIZ.DBF table. Find the record for your template in the APPWIZ.DBF file. Edit the Data1 field of the template record, and in the second line of the memo field, enter the name of your new template-specific data file. For example, the template entry in the APPWIZ.DBF file for the new PHOTO template might look like this:

Type field contents Data1 field contents
TEMPLATE Photo
PHOTO.DBF

The next time you run the Application Wizard and choose your new template, the wizard will make the default settings you have specified in the template-specific table.

Appendix: Selected Application Class Methods

The application class is defined with about two dozen custom methods and about a dozen custom properties that are used to manage the application as a whole. Most of these methods and properties are straightforward enough that they don't require much explanation.

However, a few are more complex, so they are documented completely in this appendix. By knowing how to call these methods, you can take advantage of the functionality built into your wizard-built application. For example, you can use the application class's DoForm method to display forms that you add to your application, which allows you to cascade multiple instances of your form.

Note: For a complete description of the methods and properties defined for the application class, see "Application Wizard Class Methods" and "Application Wizard Class Properties" in Help.

DoForm Function Runs a form. If specified, runs a form stored in a class library.
Syntax goApp.DoForm(cFileName, cClass, lNoMultipleInstances, lNoShow)
Arguments
cFileName The name of the form to run.
cClass Specifies the name of a class library to instantiate.
lNoMultipleInstances If .T, specifies that if the form has already been instantiated, the form is activated. If this argument is .F., a second instance of the form is run.
lNoShow Specifies that the form is instantiated but remains hidden.
Remarks
Class libraries are opened additively.
You can cascade multiple instances of the form by setting the application object's lCascadeForms property to .T. and specifying the offset for each instance of the form in the application object's nPixelOffset property.

DoLabel Function Runs a label.
Syntax goApp.DoLabel(cFileName, lPrint)
Arguments
cFileName The name of the form to run.
lPrint Specifies whether to print the label to the printer. If you pass .T. in this parameter, the label is sent directly to th eprinter. If you pass or .F. or leave the parameter blank, the label is displayed in preview mode.

DoMenu Function Displays a label.
Syntax goApp.DoMenu(cFileName)
Arguments
cFileName The name of the menu to run.

DoProgram Function Runs a program.
Syntax goApp.DoProgram(cFileName)
Arguments
cFileName The name of the program to run.

DoReport Function Runs a report.
Syntax goApp.DoReport(cFileName, lPrint)
Arguments
cFileName The name of the report to run.
lPrint Specifies whether to print the report to the printer. If you pass .T. in this parameter, the report is sent directly to the printer. If you pass or .F. or leave the parameter blank, the report is displayed in preview mode.

Release Function Closes the application.
Syntax goApp.Release()
Remarks This method closes all open forms before closing the application. This method is called from the Exit command of the File menu.

ReleaseForm Function Closes the currently activated form or a specified form.
Syntax goApp.ReleaseForm(cFileName)
Arguments cFileName The name of a specific form to release.
Remarks If no name is passed, the currently active form is closed. This method is called from the Close command of the File menu.

SetCaption Function Sets the caption of the application's main window to the specified string.
Syntax goApp.SetCaption(cCaption)
Arguments cCaption The text of the caption.

SetIcon Function Sets the icon of the application's man window.
Syntax goApp.SetIcon(cFileName)
Arguments cFileName The name of the icon (.ICO) file that contains the new icon.
Remarks The icon is displayed in the application's title bar and in the Windows­ taskbar.

Show Function Sets the icon of the application's man window.
Syntax goApp.SetIcon(cFileName)
Arguments cFileName The name of the icon (.ICO) file that contains the new icon.
Remarks The startup menu is defined as the value of the app's cStartupMenu property. This property is set initially in the application's main program. To change the startup form, change the line in the main program that sets goApp.cStartupMenu.

The startup form is defined as the value of the application's cStartupForm property. This property is set initially in the application's main program. To change the startup form, comment out the line in the main program that sets goApp.cStartupForm, and then set the application object's cStartupForm.

Event processing is started by calling the application's ReadEvents method, which first calls the application's BeforeReadEvents method. You can add code to that method to initialize the application or set property values. You can control whether the application proceeds to start event processing using the lReadEvents property (set it to .F. to cancel event processing and halt the application).

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

© 1996 Microsoft Corporation. All rights reserved. Microsoft, Windows, and Visual FoxPro are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

Other product and company names may be the trademarks of their respective owners.


© 1997 Microsoft Corporation. All rights reserved.