Dealing with User Expectations

Users tend to have ideas about how they think Windows applications should behave. Some of these ideas make sense, and some do not. Most likely, these notions are derived from features they have seen in commercial programs. Of course, your users will then expect every simple VB program you write to behave in exactly the same way.

For example, even though your program may have an Exit button, you can count on users to click the Close button in the upper-right corner. If you forget to add code to the Form_Closed event to handle this situation, your application could keep running when you don’t want it to. The following sections describe several things about which you can count on users having expectations.

Effective Menus

One important part of form design is creating consistent, effective menus. Here are some important guidelines:

• Follow standard Windows layout convention: File, Edit, View, and so on.

• Group menu items logically and concisely.

• Use separator bars to group related items in a drop-down menu.

• Avoid redundant menu entries.

• Avoid top-level menu bar items without drop-down menus.

• Don’t forget to use the ellipsis ( ... ) to denote menu entries that activate dialog boxes.

• Use standard shortcuts and hotkeys whenever possible.

• Put frequently used menu items in a toolbar.

The steps involved in using the Menu Editor and in creating a shortcut (context) menu are discussed in Chapter 10, “Understanding Windows Forms.”

→ For more details on using the Menu Editor to create context menus, see “Adding Menus to Your Forms,” p. 263

Handling Multiple Instances of Your Application

Most Windows programs are started when users navigate to a shortcut icon using the Start menu, or when they double-click a shortcut icon on the desktop. If users have multiple programs open, they can switch among them by using the taskbar or pressing Alt+Tab. However, many users like to use the program’s shortcut icon again, even if the program is already open. Some shortcuts, such as the My Computer icon on the Windows desktop, simply bring up the existing window, whereas others launch a new instance of the program.

If you provide a desktop or Start menu shortcut to your application, users may expect the shortcut to activate an existing instance of the application rather than start a new one. This is especially true if users fill out a form and then minimize it to the taskbar. They may click the shortcut expecting the form to reappear, but if you have not coded for this occurrence, another instance of your application is launched; the user will see an empty form.

For certain applications, allowing multiple instances running at the same time may be desirable. However, if you do not design this capability into your application, errors will surely occur. For example, multiple copies of your application might try to write to the same database at the same time. Fortunately, preventing users from accidentally launching extra copies of your application is fairly easy. Visual Basic .NET’s Diagnostics namespace provides a Process class, which gives your program access to processes (programs) running on the computer. The following lines of code, which can be placed in the Form_Load event or Sub Main(depending upon your application’s Startup object), will check for the existence of a previous instance of the project, and close the new instance if a previous instance is found:

If (UBound(Diagnostics.Process.GetProcessesByName _ 
    (Diagnostics.Process.GetCurrentProcess.ProcessName)) > 0) Then 
    End 
End If 

The preceding lines of code use the current process’ ProcessName property to check the list of instances of processes with that name (as reported by the GetProcessesByName method) to end the program if another instance is already running. Although this code prevents conflicts and errors, it does not help the users because they still have to find the previously started application window manually. With a few calls to the Windows API (Applications Programming Interface), you can have your program show the previous application before exiting. Listing 14.1 shows a routine that can be placed in your main (startup) form’s Code window to display the previous instance before exiting.

Listing 14.1. PREVINST.ZIP—Handling Multiple Application Instances

Private Declare Function FindWindow Lib "user32" _ 
    Alias "FindWindowA"(ByVal lpClassName As String, _ 
    ByVal lpWindowName As String) As Integer 
Private Declare Function ShowWindow Lib "user32" _ 
    (ByVal hWnd As Integer, ByVal nCmdShow As Integer) As Integer 
Private Declare Function SetForegroundWindow Lib "user32" _ 
    (ByVal hWnd As Integer) As Integer 
Private Const SW_RESTORE As Short = 9 

Private Sub Form1_Load(ByVal eventSender As System.Object, _ 
    ByVal eventArgs As System.EventArgs) Handles MyBase.Load 
    Dim sTitle As String 
    Dim hWnd As Integer 
    If (UBound(Diagnostics.Process.GetProcessesByName _ 
    Dim lRetVal As Integer 
    (Diagnostics.Process.GetCurrentProcess.ProcessName)) > 0) Then 
        sTitle = Me.Text 
        Me.Text = "newcopy" 
        hWnd = FindWindow(Nothing, sTitle) 
        If hWnd <> 0 Then 
            lRetVal = ShowWindow(hWnd, SW_RESTORE) 
            lRetVal = SetForegroundWindow(hWnd) 
        End If 
        End 
    End If 
End Sub 

In the preceding code, you first rename the current application’s form caption properties so that the FindWindow API function does not find it. Then you use three API calls to find the window belonging to the previous application, restore it, and move it to the foreground.

Perceived Speed

Perception is reality. I am referring here to how users’ observations can influence their like or dislike of your program. Application speed is a prime example. You may have written the fastest code ever, but it matters little if users think it runs slowly. VB programmers tend to get defensive when users complain about speed because “the users don’t understand how much work the program is doing.” However, you can incorporate a few tricks to make your program seem faster.

The key to a program’s perceived speed is that something needs to happen when a user clicks an icon. Users are more willing to wait if they think the computer is working as fast as it can. Booting Windows is a good example; it usually takes quite a long time. However, all the graphics, beeps, and hard drive noise keep you distracted enough to make the wait acceptable. The techniques discussed in this section give you suggestions for creating “faster” applications.

Program Startup Time

When your program starts, you probably will have some initialization to perform—for example, opening a network database. When set as your application’s Startup object, the Sub Main procedure is an excellent place for all the initialization code required at startup time.

However, this technique may cause program startup time to get a bit lengthy, so displaying a splash screen during load time is a good idea. A splash screen displays information about the program and its designer, as well as indicating to the user that some action is happening. In Figure 14.12, which illustrates a typical splash screen, notice that the mouse pointer (shown near the bottom-right of the form) has been changed to a combination arrow and hourglass by setting the form’s Cursor property to AppStarting. This indicates to the user that the program is actually doing some work while in startup mode.

Inform the Users of Progress

When your application looks like it is doing something, users tend to be more forgiving of long wait times. One way to keep them informed is to use a ProgressBar control on your form. If you are updating records in a database, you can use a progress bar to indicate the number of records processed so far. To do so, simply add an extra line of code or two to update the progress bar as you move to the next record.

→ For more information on how to display status, see “The ProgressBar Control,” p. 329

However, sometimes the progress bar is not an option. For example, Visual Basic’s FileCopy function might take some time depending on the size of the file. However, FileCopy is a self-contained “black box” function, so you have no place to insert the progress bar update code. In this case, an easy alternative would be to display some type of animation, such as an animated GIF placed in a PictureBox control or an AVI animation file placed in an

Animation control, before starting the file copy. Windows uses this trick when copying files and emptying the Recycle Bin. The users see the animation and think that it is linked to the file copy in progress when, in fact, it is a separate process running by itself.