Part IV: Professional Database Development
928
Building bulletproof forms
You can take several steps to make each form in an application virtually bulletproof:l Remove the Control Box, Min, Max, and Close buttons from the form at design time.
Your users will be forced to use the navigation aids you’ve built into the application to
close the form, ensuring that your application is able to test and verify the user’s input.
When using the tabbed documents interface, the Min and Max buttons don’t apply. The
Close button is represented by an X at the far right of the tab above the form’s body.
Removing the Close button from a tabbed form disables the X in the tab but doesn’t actu-
ally remove it.l (^) Always put a Close or Return button on forms to return the user to a previous or
next form in the application. The buttons should appear in the same general location on
every form and should be consistently labeled. Don’t use Close on one form, Return on
another, and Exit on a third.
l (^) Set the ViewsAllowed property of the form to Form at design time. This setting pre-
vents the user from ever seeing a form as a datasheet.
l (^) Use modal forms where appropriate. Keep in mind that modal forms force the user to
respond to the controls on the form — the user can’t access any other part of the applica-
tion while a modal form is open.
l Use your own navigation buttons that check for EOF (End of File) and BOF
(Beginning of File) conditions on bound forms. Use the OnCurrent event to verify
information or set up the form as the user moves from record to record.
l (^) Use the StatusBarText property on every control, to let the user know what’s
expected in each control. The Control TipText property should also be set on all rel-
evant controls.
Note
For the StatusBarText to be used, the status bar must be displayed (see Figure 26.7).
l Disable the Del key or trap the OnDelete event to confirm deletions. You can disable
the Del key by creating an AutoKeys macro to remap it to a harmless action, and you can
put use the form’s BeforeDelConfirm event to have the users confirm deletions.
Validating user input
One of the most important bulletproofing techniques is to simply validate everything the user
enters into the database. Capturing erroneous data input during data entry is one of the most
import safeguards you can build into your applications. In many cases, you can use the table-level
validation (determined by each field’s ValidationRule and ValidationText properties), but
in many other cases you’ll want more control over the message the user receives or the actions
taken by the database in response to erroneous input.
One of the major problems with the ValidationRule property is that it isn’t checked until the
user actually tabs to the next control, making it impossible to capture bad data entry. You’re much
better off in many cases validating entries in code. Very often you’ll want to validate all controls on