Printing - FoxTalk - dFPUG-Portal

isn't strictly a Windows-standard, it's what the customer requested). The main screen and each
sub-screen are stored as separate screen entries in the Project database (that is, not in a single
Screen Set), and a .PRG controls which screens are displayed at any one time.
You can now develop a sample application. All of the source code for this application is
included in download file _RUSSEL2.EXE. Since the purpose of this article is to demonstrate a
screen interface, rather than any database manipulations, this application will work only on
memory variables, which won't be saved when the application exits. Since the data is irrelevant
to the article, you won't perform any validation on the data that gets entered.
The sample application will be a prototype for a customer management system. The main
information (the information that you want to display all of the time) is the customer name and
ID. For this application, you'll have three sub-screens, each with a single piece of information.
The first sub-screen will have the Address, the second will have any Contacts that you've made
with the customer, and the third will be general notes on the customer. For simplicity sake, these
will all be character memory variables.
Define the main screen loop
All of the processing for this screen is controlled from within a single .PRG that calls multiple
.SPR files. The screen files all have the #NOREAD directive and, therefore, can't do anything
more than display the information on the screen. This means that the controlling .PRG contains
the controlling READ. Here's a sample of the controlling loop. In this case, the READ SHOW
and READ WHEN procedures aren't defined; the calls are just for illustrative purposes: