Contents of the APGENUA.TXT file

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

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

AppGen Users AnonymousGilbert Catipon

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

Being an Applications Generator user is no shameful admission. In thescheme of things, having a means of assembling an entire applicationthat looks sharp and performs well is quite a luxury. And while youmay hear the occasional rumbling of long-time dBASE developers sayingthat they would never use the Applications Generator, they undoubtedlystill have the image burned in their brains of an ApplicationsGenerator 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. Theremay be some tricky corners to handle when it comes to plugging in allthe right components that will result in a well-running application. Remember, AppGen has to account for a number of user-changeableoptions. This can ultimately result in a sense of overkill. So manyoptions, so little time. Sometimes, it feels like all those submenusand options get in the way and make things more confusing. Butremember how difficult a bike was to steer when it had trainingwheels? Or for that matter, remember how difficult it was to get yourfirst gratifying output from a personal computer?

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

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

In designing applications, a common need is to copy data to and fromfloppy disk for transport to another machine or simply to backup thedatabase. 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 diskin drive A, an error box prompts

Drive not ready on A:Cancel Retry Ignore

If the user selects Cancel, the application halts immediately andrather awkwardly. If the user has the initiative and forethought toplace a disk in drive A and select Retry, then the application isfine. But there is that brand of user: you know, the optimisticsun-will-come-out-tomorrow type that believes if you ignore something,it will go away. So, if the user selects Ignore, the application willnot know this and our problems are compounded. Most users will panicwhen they see this message and choose the first selection, Cancel,putting a disquieting and unprofessional-looking end to yourapplication. To counteract this, create the file COPY2A.PRG, listedbelow, enter the Applications Generator design for your applicationand choose Item: Change action: Run program: Do dBASE program, thentype 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 ofwhich option they choose the ON ERROR routine will verify whether theyreally want to cancel or retry the operation. If the user decides notto retry, we then display a message accordingly.

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

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

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 ERRORRETURN