This article is reprinted from the January 1991 edition of
TechNotes/dBASE IV. Due to the limitations of this media, certain
graphic elements such as screen shots, illustrations and some tables
have been omitted. Where possible, reference to such items has been
deleted. As a result, continuity may be compromised.

TechNotes is a monthly publication from the Ashton-Tate Software
Support Center. For subscription information, call 800-545-9364.

AppGen Users Anonymous
Gilbert Catipon

The room was deafeningly quiet. The eyes of each member of the group
were focused on him, waiting for his first words. Slowly, he mumbled,
"I've been using AppGen for some time now." There! It was said. The
words fell off his lips like the confession of remorseful sinner.
Then, with a spark of defiance, he continued, "I also have three sets
of Ginzu knives, a Craftmatic bed, a GardenWeasel, a TurboWash and six
Clap-on/Clap-off remotes, so sue me!"

Being an Applications Generator user is no shameful admission. In the
scheme of things, having a means of assembling an entire application
that looks sharp and performs well is quite a luxury. And while you
may hear the occasional rumbling of long-time dBASE developers saying
that they would never use the Applications Generator, they undoubtedly
still have the image burned in their brains of an Applications
Generator that till now was nothing more than the fancy .PRG file.

But now, AppGen is an integrated design interface in dBASE IV. There,
you have the ability to develop fairly complex applications. There
may be some tricky corners to handle when it comes to plugging in all
the right components that will result in a well-running application.
Remember, AppGen has to account for a number of user-changeable
options. This can ultimately result in a sense of overkill. So many
options, so little time. Sometimes, it feels like all those submenus
and options get in the way and make things more confusing. But
remember how difficult a bike was to steer when it had training
wheels? Or for that matter, remember how difficult it was to get your
first gratifying output from a personal computer?

Nonetheless, some of the little headaches one develops along the way
don't quite drive home the comforting assurance of such cozy
metaphors. For instance, have you ever thought how nice it would be
to be able to use a floppy drive from a menu that wouldn't crash your
application just because the user failed to insert a floppy disk?

This article shows how to check whether a disk operation was
successful and not cancel the application in progress. This article
assumes that you are somewhat familiar with the Applications
Generator; if you have never set up an application using the
Applications Generator, follow the steps on pages 2-4 through 2-6 in
Using the dBASE IV Applications Generator . If not, you can still use
the code in your own programs with some modification.

In designing applications, a common need is to copy data to and from
floppy disk for transport to another machine or simply to backup the
database. So you define the action of an item to be

COPY TO A:\BACKUP1.DBF NEXT 30

The problem is that if the user fails to put a properly formatted disk
in drive A, an error box prompts

Drive not ready on A:
Cancel Retry Ignore

If the user selects Cancel, the application halts immediately and
rather awkwardly. If the user has the initiative and forethought to
place a disk in drive A and select Retry, then the application is
fine. But there is that brand of user: you know, the optimistic
sun-will-come-out-tomorrow type that believes if you ignore something,
it will go away. So, if the user selects Ignore, the application will
not know this and our problems are compounded. Most users will panic
when they see this message and choose the first selection, Cancel,
putting a disquieting and unprofessional-looking end to your
application. To counteract this, create the file COPY2A.PRG, listed
below, enter the Applications Generator design for your application
and choose Item: Change action: Run program: Do dBASE program, then
type into the prompt area COPY2A. For the Parameters option, enter :
"A:\BACKUP1.DBF","NEXT 30" Yes, the quotes are required.

When the application is executed and the user selects the menu item,
they will still get the Drive not ready message, but regardless of
which option they choose the ON ERROR routine will verify whether they
really want to cancel or retry the operation. If the user decides not
to retry, we then display a message accordingly.

If you haven't had a chance to look at the code generated by the
Applications Generator, you might wonder where the window and
procedure, both named PAUSE are defined. The window and procedure are
defined in the main application .PRG file. If you don't want to take
advantage of AppGen and then simply create an appropriate PAUSE
procedure and window or copy it off of a generated application
file.

Well there's one AppGen crisis under control. Watch your anxiety
level and if it gets too much, remember, help is just a phone call
away.

COPY2.PRG
PROCEDURE Copy2a
PARAMETER wcfile,hwmany

diskok = .T.
ON ERROR DO diskrtry
COPY TO (wcfile) &hwmany
ON ERROR DO pause WITH [The error occurred at line ] ;
+LTRIM(STR(LINENO()))+[ of " ]+PROGRAM()-[.PRG "]
IF diskok
* You can insert additional code if disk was OK, i.e.
DIR A: *
*
*
ELSE
DO pause WITH "Warning! Disk operation failed."
ENDIF
ON ERROR
RETURN

PROCEDURE diskrtry
ON ERROR
diskrtry = .T.
ACTIVATE WINDOW pause
@ 1,1 SAY "Drive not ready on A: Retry?(Y/N)" GET diskrtry
PICTURE "Y"
READ
DEACTIVATE WINDOW pause
IF diskrtry
RETRY
ELSE
diskok = .F.
ENDIF
RETURN
*EOP: Copy2.PRG