Advanced Visual Basic Techniques
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471188816
Publication Date: 06/01/97

Chapter 2
Building the ExpenseReporter

Chapter 1 described ExpenseReporter from the user’s point-of-view and explained some of the important programming methods used to build the application. This chapter continues the discussion of the methods used to build ExpenseReporter.

The next section, “Key Techniques,” briefly describes the topics covered in this chapter. The sections that follow describe these techniques in detail.

Key Techniques

The following list briefly introduces the key techniques described in the rest of this chapter:

•  Providing Feedback. When a user interacts with an application, the application should provide prompt, appropriate feedback. This section explains how an application can use feedback to appear responsive while letting the user know it is working correctly.

•  Validating Data. An application should protect itself from the user’s entering invalid data. This section explains how ExpenseReporter allows the user to enter only appropriate data in its fields.

•  Validating Forms. Some validations cannot occur until the user has finished entering data. This describes ExpenseReporter’s form-level validations.

•  Printing. Printing is one of the most complicated subjects in Visual Basic programming. This section shows how ExpenseReporter uses the Printer object to provide high-resolution printouts.

•  Print Previewing. Allowing the user to preview a document before printing it makes an application appear more professional. This section describes methods an application can use to simplify print previewing.

•  Printing with a Dialog. Some applications allow the user to specify the number of copies to be printed or the range of pages to be printed. This section explains how an application can provide a dialog to allow the user to select these options while printing.

•  Providing Printer Setup. A high-quality application that provides printing features should also allow the user to select the printer and specify its properties. This section shows how an application can invoke the standard printer setup dialog.

•  Providing Help. Every application must provide help. This section tells how to build and use a help file.

•  Providing Context-Sensitive Help. Context-sensitive help allows the user to obtain information about specific parts of an application’s user interface. This section explains how a program can provide this feature.

•  Displaying About Dialogs and Splash Screens. Although easy to implement, about dialogs and splash screens make applications appear more professional. This section tells how a program can display these forms with little effort.

Providing Feedback

When a user interacts with an application, the application should provide immediate feedback so the user knows the program is working correctly. Feedback also makes the application appear more responsive because the user receives feedback when a task begins rather than only when it ends.

Many interactions between a user and an application provide their own feedback. When a user adjusts ExpenseReporter’s vertical scroll bar, the expense rows that are visible change. When the user types into a text box, the text is immediately visible. ExpenseReporter goes to some lengths to ensure that the text box that has the input focus is always visible. Otherwise, the feedback is lost, and the user has little confidence that the application is behaving correctly.

Other operations do not provide feedback on their own. When an application prints a file, there is no feedback unless the application intentionally provides it. A user who does not know the print operation is in progress may press Ctrl-P several times and start several print jobs.

The easiest way to indicate that a long operation is in progress is to change the application’s mouse cursor to an hourglass. A Visual Basic application can do this using the WaitStart subroutine shown in the following code. The WaitEnd routine restores the cursor to its default shape.

Sub WaitStart()
    MousePointer = vbHourglass
    Refresh
End Sub

Sub WaitEnd()
    MousePointer = vbDefault
End Sub

WaitStart and WaitEnd work only for the current form. If an application displays more than one form, it must change the cursors for each form separately. An application can use the following version of WaitStart and WaitEnd to change the cursors for every loaded form.

Sub WaitStart()
Dim frm As Form

    For Each frm In Forms
        frm.MousePointer = vbHourglass
    Next frm
    Refresh
End Sub

Sub WaitEnd()
Dim frm As Form

    For Each frm In Forms
        frm.MousePointer = vbDefault
    Next frm
End Sub

An application must be certain to call WaitEnd every time it calls WaitStart. If a subroutine invokes WaitStart and then exits before it calls WaitEnd, the cursor will remain an hourglass. This can be particularly tricky if a routine that uses an On Error statement invokes a subroutine that uses WaitStart. If the second routine generates an error, control returns immediately to the outer routine’s error-handling code without giving the subroutine a chance to call WaitEnd.

To prevent this problem from occurring, the inner subroutine should also use an On Error GoTo statement. Its error-handling code should call WaitEnd and then use the Err object’s Raise method to pass the original error up to the calling routine.

When an application performs very short operations, WaitStart and WaitEnd may not work. If the operation is too quick, the user will not be able to see the hourglass cursor. One solution is to use a timer control to make the program delay a short while before calling WaitEnd. This may seem like a waste of the user’s time. If the delay is only half a second or even a full second, the user loses very little time and has gained important feedback.

An even better solution is to present feedback in a visible but unobtrusive form. If the application has a status bar, it can place a message there. For example, when the user saves a file, the application can make the status bar say “File saved.” This method works only if the status bar message changes frequently. If the message bar still says “File saved” the next time the user saves a file, the user will not be able to tell that a new message has appeared.

One way to guarantee that status bar messages change frequently is to use a timer control. After presenting the “File saved” message, the application can activate a timer that blanks the message in two or three seconds.

Another visible indication for file saving uses the form’s caption. When no file is associated with the data displayed by ExpenseReporter, the program’s caption reads “ExpenseReporter [ ].” If the user loads the data in the file C:\1_1_97.EXP, the caption becomes “ExpenseReporter [C:\1_1_97.EXP].” When the user modifies the data, the program adds an asterisk, as in “ExpenseReporter * [C:\1_1_97.EXP].” After the user saves the changes, the program removes the asterisk. These techniques allow the user to determine quickly the name of the data file loaded and whether any unsaved changes have been made.