Introduction to Building an Application in Visual FoxPro 3.0
Scott Cooper
Microsoft Corporation
Introduction
This session is a must for those of you who are new to Visual FoxPro and will provide an introduction to new tools and programming techniques that should be valuable to experienced FoxPro developers as well. We will take a high level look at the major components of a FoxPro application and the designers that are used to create them. Next we will explore some simple methods of tying the pieces together into a single cohesive application.
With Visual FoxPro, you can easily create event-driven, object-oriented applications one piece at a time. This modular approach allows you to verify the functionality of each component as you create it. Once you have created all the functional components, you are ready to compile them into an application.
Creating a functional application typically requires these steps:
The Project Manager is designed to be the main hub of Visual FoxPro acting as both a file organizer and an application compiler. It provides an easy, visual way to organize and work with tables, databases, forms, reports, queries, programs, and other files when creating an application.
It has been enhanced with many new features to make it more useful in its expanded role as the main container in the design process including:
Defining the Data Schema
The first step in creating an application is to design the tables that your application will use and specify how these tables are related.
As with earlier versions of FoxPro you can define independent tables using the Table Designer. You will want to continue using these “free tables” if you require compatibility with earlier versions of FoxPro. If compatibility is a concern be careful not to use any of the new data types (Double, Currency, DateTime) or the new NULL capability.
Visual FoxPro 3.0 allows you to define a database which is a collection of tables and their related rules and properties. By adding tables to a database you are able to
The database designer allows you to create a database visually. Add existing tables or create new ones using the table designer.
Define persistent relationships by dragging an index from one table to the index of another table. These relationships will automatically be used by other parts of the product including the query, view, and data environment designers.
When a table is in a database, the table designer presents additional options including the ability to define default values, “friendly” table and field names, and business rules at the field and table level.
For more complex business rules that require procedure code you may opt to use a stored procedure. Stored procedures are code modules that actually live in the database as opposed to being a separate file on disk. When a database is open, program scoping is modified so that FoxPro first looks to see if the desired function exists as a stored procedure before continuing on the standard search path.
You may also want to enforce referential integrity on your tables. You can use FoxPro’s Referential Integrity builder to enforce RI or you may choose to write your own code using rules and triggers.
Visual Designers
A typical database application consists of data structures, a user interface, query options and reporting capabilities. An assembled Visual FoxPro application often presents a user with a menu and one or more forms for entering or displaying data. You provide specific functionality and maintain data integrity by attaching code to certain events. Queries and reports then allow your users to extract information from the database. Visual FoxPro provides visual designers to make it easy to create these components. We’ve already examined the Database Designer, now let's take a look at the Form Designer...
Form Designer
Use the form designer to create both databound forms and dialogs. When working with databound forms you will typically want to define the data environment for the form, add controls to the form, attach code to handle events, then test the form.
Defining the Data Environment
The Data Environment defines the tables that the form will use at run time and specifies how these tables are related. When a form is opened, any tables in its Data Environment are automatically opened. When the form is closed, the tables are closed.
You can access the Data Environment Designer in three ways:
Add tables or views to the Data Environment by selecting the Add Table item from the Data Environment menu, by bringing up a Right-Click menu for the DE, or by dragging tables from a project and dropping them on the surface of the DE Designer. Notice that any persistent relations that have been defined at the database level are automatically inherited. If necessary, define additional relationships by dragging a field from the parent table to an index of the child table.
Adding controls to the form
Now that the Data Environment for the form has been defined you need to add controls to the form. You can use the controls pallet to drop single controls on the form but there are several shortcuts that will help speed your development:
Once controls have been added to the form, use the property sheet to set properties of controls or the form itself.
Attaching code to events
You will likely want to write code which will be triggered by certain events. To bring up the code window double click on an object or a specific event in the Methods tab of the property sheet. From the code window you can use the Object and Procedure dropdowns to quickly examine the code attached to any event.
Testing your form
Typically when designing a form you will repeat the cycle of testing the form, re-entering design mode to make modifications, then testing it again. The easiest way to do this in FoxPro 3.0 is to use the run button on the standard toolbar. Clicking this button will run the form. When the form is closed, it will automatically be re-opened in design mode.
Class Designer
One of the most exciting features of FoxPro 3.0 is the ability to define classes visually. Working with the class designer is virtually identical to working with the form designer and since there are several sessions devoted to working with classes and the object model, I’ll let others get the glory.
Query / View Designer
Queries allow you to view fields from one or more tables which match specified criteria. As with earlier versions of FoxPro you can use the Query Designer to create SQL queries which return a result set. These queries are stored as a separate file on disk with a .QPR extension.
New to FoxPro 3.0 is the View Designer. Like queries, views use SQL to define a result set using one or more tables which match a specified criteria. In addition, views create an updatable cursor. Users may edit the data in the result set and it will be written back to the underlying tables. Views are not a separate file of their own. They are contained in a database.
FoxPro 3.0 also supports remote views which are based on tables in an ODBC data source.
The Query and View designers are virtually identical. Both queries and views can be used to browse a data set or to create a cursor to use in processing or reporting. Views can also be used as the basis for databound forms.
Report and Label Designers
The report designer is used to create formatted output. FoxPro 3.0 continues to use the familiar banded report writer in which fields are placed in header, detail, or footer bands. The detail bands are repeated for every record in the data set.
New Features for the FoxPro 3.0 report writer include:
Labels are just a specialized form of reports which allow you to create formatted output to fit on standard label stock.
Menu Designer
The menu designer allows you to create custom menus for your application. The easiest way to start is to select the Quick Menu item from the “Menu” menu. This will create a standard FoxPro menu from which you can remove unwanted items and add your own.Tying the components together
Once you have created the components of your application, you need to tie them all together. Creating a main.prg is a simple way of doing this. There are several things you will typically want to do in this program:
For example, your main program might look like this:
DO setup.prg && Call the program to set up the environment.
DO mainmenu.mpr && Display a custom menu.
DO FORM welcome && Display a welcome form.
READ EVENTS && Establish the event loop.
DO cleanup.prg && Restore the environment after exiting.
Setting up the Application Environment
The default Visual FoxPro development environment might not be the best environment for your application. The default environment establishes certain values of SET commands and system variables when Visual FoxPro opens.
Tip To see the default values of the Visual FoxPro development environment, start Visual FoxPro without a configuration file and use the DISPLAY STATUS command.
It is a good idea to save existing settings, set up the environment for you application, then restore the original settings when you application exits. For example, if you wanted to set TALK to OFF for your application, you could save the initial setting with the following code:
IF SET('TALK') = "ON"
SET TALK OFF
cTalkVal = "ON"
ELSE
cTalkVal = "OFF"
ENDIF
Other environment settings you may wish to create for you application include:
Display the initial user interface
The initial user interface may be a sign-on screen, menu, form, or any other user component. In our example we use the main.prg to display a custom menu and a welcome form.
Controlling the Event Loop
Once the environment is set up and you have displayed the initial user interface, you are ready to establish an event loop to wait for user input. The event loop begins when you issue the READ EVENTS command. Once this command has been executed your program execution will be paused waiting to respond to events. To remove the application from the event loop you can execute a CLEAR EVENTS command. This will cause execution to continue with the line following your READ EVENTS command.
Important You need to establish a way to exit the loop before you start it. Make sure your interface has a mechanism (such as an Exit button or menu command) to issue the CLEAR EVENTS command before executing READ EVENTS. If you fail to do this you might find yourself in an infinite loop that requires hitting the ESC key or rebooting your computer.
Restoring the Original Environment
To restore the original value of saved variables, you can macro-substitute them into the original SET commands. For example, if you saved the SET TALK setting into cTalkVal, issue this command:
SET TALK &cTalkval
Note Variable names used with macro substitution should not contain the “m.” prefix because the period assumes a variable concatenation and will produce a syntax error.
Compiling your files into a single application
The project manager allows you to compile all your components into a single .app file. To do this you will want to
To set the starting point for an application
Each project has a main file which serves as the execution starting point for your application. It can be any program, form, or query file included in a project, but is typically a program or form. Setting the main file can be done by:
Only one file in the project can be set as the main file. The main file is designated by a · symbol as shown below:
To combine the functionality of the main program and the initial user interface, you might want to use a form as the main program. In this case, you could add code to the form to preserve the initial environment and restore the initial environment when the form is closed.
If the user closes the main form, you often want to close the application. Including CLEAR EVENTS in the Destroy event of the form is a good way to do this.
Excluding files from your application
When you build an application, all files included in a project will be compiled into a single file with the .APP extension. All included files, including tables, will be read-only as a part of the .APP file. If your project includes tables or other files that your users need to modify, those files must be marked as excluded. To exclude a file:
Excluded files have the Æ symbol to the left of their names as shown below:
Building the .app file
To verify references and regenerate any components that have been updated since the last build, rebuild the project.
Build errors are collected in a file in your current directory with the name of your project and an .ERR extension. The compilation error count is displayed on the status bar. To have the error file open in a window immediately following the build process, check the Display Errors check box. Using the Display Errors check box on the Build Option dialog is the best way to get a listing of compilation errors. For more information on building projects, see the BUILD PROJECT command in Help.
When you build a project, any errors found in the project files are reported. If you are able to build the project without errors, you are ready to build the application.
If you have the Professional Edition of Visual FoxPro, you can choose to create either an application or a stand-alone executable file.
.APP files vs. .EXE files
Visual FoxPro builds files in two forms: .APP files referred to as "applications" and .EXE files referred to as "executables." The execution of the file differs only in the product required to build it, the environment in which it must run, and licensing for distribution. .APP files can only be run from an existing copy of FoxPro. .EXE files can be run as stand-alone applications.
| Feature | Applications (.APP) | Executables (.EXE) |
| Visual FoxPro Edition | Standard and Professional | Professional, only |
| Building | Project Manager orBUILD APP command | Project Manager orBUILD EXE command |
| Execution | Requires Visual FoxPro | Runs stand-alone |
| Distribution | Requires individual or site-licensing | Distributable royalty-free |