The root of the Windows operating system lies in a concept of the common user interface. A common “look and feel” assures users that what they learn for one application can be a basis for working with another. Unfortunately, developing the now-familiar Windows “look and feel” requires complex code. Before Visual Basic’s release, this complex coding made the Windows development process difficult. You had to concentrate on the underlying code first rather than the interface for which Windows has become so well known.
Visual Basic answers this challenge with its new emphasis on designing the user interface before writing the code. Now you can quickly and easily design the user’s screens before writing a single line of code. This important change enables programmers to concentrate on what the user sees rather than how to make the application work in Windows.
Visual Basic now makes it easy for programmers to create Windows application. Companies all over the world are taking advantage of the flexibility of the Visual Basic environment to provide highly customized internal applications. These applications were almost impossible to create before the release of Visual Basic.
In the years to come, Visual Basic will provide great opportunities. Companies can take advantage of easy interface design to develop applications that precisely fit the needs of users. A dialog between developers and users will result in better applications with smaller periods of time between releases.
These same opportunities, however, also present challenges. All programs that you develop in Visual Basic are subject to all the limitations of the Windows environment. Unfortunately, these limitations are not always apparent to the beginning Visual Basic programmer.
In this chapter, you learn how to do the following:
Visual Basic’s wide range of features are a two-edged sword that creates both opportunities and challenges. The opportunities lie in the flexibility to give the user what he or she needs. The challenges lie in achieving the first goal without creating problems that make the resulting application difficult to use or, worse, unusable. When users ask for so much detail and control that the application becomes unwieldy, you should examine which side of the sword the interface is on. There is always a tension between what a programmer can do and what he or she should do. It is a narrow path, and being aware of the pitfalls makes it easier to avoid them.
When designing a Visual Basic application, you should ask two basic questions:
Keep these two questions in mind in the following discussions.
One of Visual Basic 3.0’s greatest strengths is the wide variety of .VBX controls available from third-party companies. Even with the new .OCX format, Microsoft has provided third-party companies with a lengthy beta cycle. This cycle has enabled many of the major companies to prepare .OCX versions of their popular .VBXs controls. When Microsoft releases Visual Basic 4.0, most of the major Visual Basic add-in companies should already have .OCX controls available.
Third-party controls enable programmers to choose solutions for a variety of both specialized and generalized challenges. Such controls include specialized data bound list and combo boxes, project lists, calendars, and many more. Some programmers might feel that these controls are no longer necessary because of the new ones that ship with Visual Basic 4.0. The reality is that no “magic bullet” control exists that will satisfy every programmer and user. Each situation and need differs, and probably can be addressed by an available control.
Make sure that you do not become too dependent on fancy controls. Use your head rather than controls to design your applications. Your brain is the most powerful tool that you will ever find to help you design applications. Think about what you want your application to do and how you can do it. If after considering all the possibilities you still decide that you need a custom control, use it. But keep the following in mind: Custom controls are almost always faster than written code, and graphical controls always affect performance. Try to find internal Windows API calls that can accomplish the same thing that you are trying to achieve with controls.
With the release of Windows 95, programmers face the challenge of designing applications with the newer interface. Many of the features of Windows 95 are familiar as part of the growing trends that began long before the release of Windows 95. The most obvious element of the Windows 95 interface is its three-dimensional (3-D) appearance.
For the past few years, developers have been creating applications that feature controls that have a 3-D appearance. Visual Basic 3.0 shipped with several 3-D controls. Many third-party .VBX companies provided methods for creating applications that have a 3-D appearance. A 3-D appearance is nothing new to veteran Visual Basic programmers. Table 34.1 lists upgrades to the 3-D controls that shipped with Visual Basic 3.0. You can find these upgrades in THREED32.OCX.
Table 34.1 The 3-D .OCX Controls in THREED32.OCX
| Name | Description |
| SSCheck | 3-D check box |
| SSCommand | 3-D graphical command button |
| SSFrame | 3-D frame |
| SSOption | 3-D option box |
| SSPanel | 3-D progress indicator and label |
| SSRibbon | 3-D toolbar button |
What is new to Visual Basic programmers is a development environment and operating system that have a built-in 3-D appearance. Visual Basic 4.0 includes controls and tools designed to provide an application that looks perfectly at home in the Windows 95 operating system. In fact, Visual Basic 4.0 ships with controls specifically designed for use with Windows 95. Table 34.2 lists these controls, which are available in COMCTL.OCX.
Table 34.2 The 3-D .OCX Controls in COMCTL.OCX
| Name | Description |
| ProgressBar | 3-D progress indicator |
| Slider | 3-D slider |
| StatusBar | 3-D status bar |
| TabStrip | 3-D tabs |
| ToolBar | 3-D toolbar |
| TreeView | 3-D outline |
Under Windows 3.x and Visual Basic 3.0, 3-D appearance affected performance. Applications that used too many 3-D controls ran slowly. By using 3-D controls, applications tested the limits of Windows 3.x’s memory-management system. For this reason, your application’s screens must use as few 3-D controls as possible.
With the release of Windows 95 and Visual Basic 4.0, you might think that the 3-D challenge has disappeared. After all, if Microsoft designed both the operating system and development environment for creating applications with a 3-D appearance, surely you no longer need to worry about using 3-D controls in the applications that you develop. But although Microsoft has eliminated or at least loosened the memory and resource limits on 3-D controls, the interface limits still exist.
Even if you could give your applications as many 3-D controls as you want, does that mean that your applications will look better? In the screen shown in figure 34.1, one 3-D frame that fills the entire form contains all the controls.
A screen demonstrating a gross overuse of graphical 3-D appearance that degrades an application's performance.
Such a layout is unnecessary for the interface. All forms start with their Appearance property set to 3D, so putting a frame around the form’s controls serves no purpose. Frames are terrific controls for organizing information on the screen to make the screen more readable. However, using too many screens, as in figure 34.1, has the opposite effect of causing more confusion.
Notice in figure 34.1 the overuse of the SSPanel to hold every control on the form. All the command buttons are in one frame. However, each command button has an obvious label directly on it. To indicate that a group of buttons are related, you can simply place them in the same area. Each of the controls would look better if you use a label rather than a frame to differentiate them.
Figure 34.2 shows an appropriate use of 3-D controls. This screen uses frames only to organize similar controls. You save much screen space this way. Notice also how much more easily you can read the information on the screen.
A screen demonstrating a much better implementation of 3-D appearance.
Simplify your screens whenever possible. If you have trouble determining what a screen does, you can’t expect the user to understand it. Using many frames just makes the screen more complex and make it harder for a user to read and understand it.
Many applications place pictures on their command buttons, and several popular applications are displaying check marks and X marks on their OK and Cancel buttons. You might be tempted to do the same, particularly because the SSCommand button provides an easy way to display a picture on a command button. However, resist the temptation to include command buttons with graphics, for two reasons: because doing so is a nonstandard Windows style, and because the buttons frequently take up too much screen space for little or no benefit.
Visual Basic Professional Edition ships with three different kinds of graphical controls: Image, Picture, and Picture Clip. These controls can make a Visual Basic application much easier to use.
Placing too many Picture controls on one form, however, has a detrimental effect on Windows resources. One large graphic has the same kind of significant effect on Windows resources. If your application does not require the use of Picture controls, use an Image control instead. The Image control uses fewer Windows resources. Don’t clutter your screens with too many graphics, because doing so only confuses users by giving them too much to look at.
Visual Basic provides two powerful control types: the list box and the combo box. With these controls, the programmer can provide the user with a choice of selections and thus limit user entry problems. Entries that different data-entry people make with these controls appear the same way in the resulting database.
Overusing list boxes and combo boxes can also harm an application’s performance. If a list box or combo box lists too many items, the control can increase the load time of the form to which the control belongs. You can reduce the number of items in a list by finding out what the actual limits are. Does a user need all the states in the United States, or only the 10 with which the company normally does business?
Limits on the Number of Controls
There are practical limits to how many controls that you should place on any one screen. This limit is much smaller than the maximum that Visual Basic allows. The actual limit depends on the purpose of the screen that you are designing. As a general rule, try to design each screen with a single purpose in mind; then use only as many controls as are necessary to support that purpose. If any controls stray or detract from that single purpose, remove them.
Visual Basic makes it easy to add a form to an application. To add a form or module, simply click on the appropriate icon. You need not write any supporting code for forms or modules. Although these icons make it easy to add a screen to an application, they also present challenges.
When users click on an icon, they like to see something happen. Unless the application appears to take some kind of action, some users become confused and begin to suspect that the program doesn’t work. Users might perceive an application with many forms as “slow” because it is constantly loading and unloading the forms. This loading and unloading also confuses users and creates a performance problem as well.
Whether an application is “slow” or “fast” is all a matter of the user’s perception. If users see something happening on screen while an application is executing, they perceive the application as “fast” rather than “slow.” The techniques described in this section help you to create “fast” applications.
Avoid displaying the control box on forms that have command buttons. If the user is to exit from a form by using one or a choice of buttons, the control box provides a tempting alternative. This frequently overlooked problem can have devastating effects on your application and data if it causes your application to miss initiating critical processes connected to the command button.
If you load all a program’s forms at program startup, they all appear quickly when the application calls them. Although this slows the application’s performance at program startup, the application’s run-time performance is much faster. Simply load all the forms that belong to an application by using the load method. This method places the forms in memory but invisible.
This technique works well for applications with a small number of forms (2 to 5). For applications with more forms, you might use this technique for similar groupings of forms. For example, an accounting payroll application might load all the forms associated with displaying employee information during an employee data-entry session.
The Options dialog box (which you display by choosing Tools, Options), has a Project tab that enables you to change the startup form to Sub Main. Figure 34.3 shows the Options dialog box’s Project tab. To take advantage of this setting, you need a module with a Main subroutine. This frees you from having to keep any startup routines within a form’s load event.
The Project tab of the Options dialog box.
The Sub Main subroutine is an excellent place for all the startup code required at startup time. For example, the Sub Main subroutine might contain code for checking the application’s path. You might place a splash screen on the screen while the subroutine checks this path.
One way to deal with lengthy program startups is to display a splash screen during load time. A splash screen is a borderless form that displays information about the application and its designer. Many commercial applications, including Microsoft Word and Excel, display splash screens at program startup. A splash screen provides the user with visible proof that something is happening. Figure 34.4 shows a typical splash screen.
An example of a splash screen that appears when the application first loads to give the user something to look at while configuration takes place.
Applications sometimes must initiate lengthy processes that force the user to wait while they are taking place. (Whether a process is “lengthy” depends on the perception of each individual user, but usually a process that takes more than 10 seconds is considered lengthy.) To most users, simply showing an hourglass or simply leaving the mouse pointer displayed is insufficient. Users like to see some indication that the program is doing something. One of the best ways to provide such an indication is to display a progress indicator on the screen. A progress indicator can be either a modal dialog box or information displayed in the status bar at the bottom of the screen.
Progress Dialog Boxes
A progress dialog box (fig. 34.5) usually consists of a borderless modal form with some kind of message and graphical representation of progress. One of the best Visual Basic controls for the graphical display is SSPanel. This control shows the user both a graphical gauge and a percentage indicator, giving the user two kinds of visual information to indicate that the application is doing something. To indicate progress, the control fills with color and displays a percentage.
An example of a progress dialog box, which appears over an application's screen during a process.
Progress Status Bars
Applications with a status bar can change one of the panels to indicate progress. Many applications, including Microsoft Word and Excel, use this method. A bonus benefit of using progress status bars is that you use existing screen controls and thus need not add another form.
Figure 34.6 shows a typical multiple-document interface (MDI) screen with a status bar at the bottom of the screen. Notice the colored portion of the bottom of the status bar and the percentage figure in the center. This figure demonstrates one way to show a percentage indicator in the status bar.
An example of a status bar progress indicator showing at the bottom of the application's screen the percentage of work currently done.
Chapter 30, “Advanced Control Techniques,” explains in detail the status bar and its purpose in a Visual Basic application. Also examine the status bar in SHELL.MAK on the companion CD.
Remember that other people will use the applications that you write. Most users are not as sophisticated about many of the basic concepts in Windows design. They seldom care about anything except doing their work as quickly and as easily as possible. As a programmer, your job is to design applications that make the user’s job easier.
Many companies are using Visual Basic to replace old 3270 emulation screens. Programmers designing these new screens must be careful not to simply replicate the older 3270 screen in Visual Basic. The screens need not appear exactly the same as they did in the older applications. You can consolidate some screens into one screen; conversely, you might need to divide a screen into multiple ones. Many new techniques are available to the programmer to solve such problems.
Visual Basic provides an easy method for displaying list choices to the user. Many older screens required users to know what they had to enter in a particular field. Lists provide users with a choice of items to enter in a field, reducing the chances of the user becoming confused and making entry errors in the field.
The 3270-style screen expects the user to know what to do. Such a screen prompts the user for information, such as the state, but does not specify which format to use. The user must know, for example, exactly which states the company does business in and which format to use when entering that state. Database systems are not very intelligent; for some, “ny” and “NY” are two different states. The 3270-type screens offer few safeguards to prevent users from entering information that confuses the system.
Command buttons control a screen’s basic functions. The names on each of the buttons provides the user a catalog of available actions. If you present command buttons in different places on the same screen in a seemingly random structure, you can confuse the user. Any structure is acceptable; you can place all the buttons along the top, bottom, or (more commonly) right edge of a screen (see fig. 34.7).
A well-constructed screen with all the command buttons placed on its right side.
To present a fixed number of choices, use the check box and option box controls. A check box gives the user two choices only: on or off. For example, you might use a check box to indicate whether to display the current hold status of a sales order. An option box presents the user with a fixed list of choices. For example, you might use an option box to display a list of the states in which a company does business.
Users are focused on the tasks that they want to do. They don’t care about how difficult it is for a programmer to produce something for them. They only want what they need to do their job. Sometimes users have trouble articulating what they want, and often what users think they want is not what they actually need. The programmer’s job is to get users’ required tasks on a screen within an application. Learn to listen to users to discern their underlying requirements. Finally, always be prepared to go through several iterations of screens before you find the right solution for a user.
Be careful not to create application interfaces that are flashy and dazzling, but which actually aren’t very usable. Using tabbed screens, for example, might be the latest trend in programming, but if it doesn’t help users do their job, try something more practical. Don’t force features on users unless they need them.
Programmers use terms and concepts that often differ from those familiar to users. Conversely, users work with different concepts and terms with which they are familiar. Your applications should use the concepts and terms that fit the needs of users and avoid using those familiar to programmers (unless your application’s users are other programmers). In other words, instead of displaying the phrase “Initiating variables,” use the more accessible “Preparing system.” Simply by avoiding the use of programmers’ jargon, you can make your application more understandable to users.
Most Windows applications have a consistent “look and feel,” including the now-familiar control boxes and maximize and minimize buttons. Most applications now have the 3-D appearance with a gray background and black text. Most command buttons have either text or icons that indicate the button’s function.
You should consider very carefully before you vary from these Windows standards. The purpose of the common user interface is to give users a familiar environment in which knowledge of one application largely applies to another. To the extent that you vary from these standards, you place your application’s users into a foreign, unfamiliar environment.
Many Windows users like to change the default colors to those of their preference. Unfortunately, this presents a problem for the programmer. If you change the default colors at design time, those colors might conflict the user’s choices. In such cases, the interface might become unusable. Consider the result, for instance, of the user choosing yellow text against a blue background. If you change the text color to blue, the blue text disappears into the blue background.
Some very popular Windows applications include graphics and text on the same buttons. This style, although quite popular, is inadvisable for several important reasons. Such command buttons take up a great deal of screen real estate and consume a large amount of Windows resources. Avoid using these nonstandard buttons.
Many different kinds of applications are available for the Windows environment, including word processors, spreadsheets, accounting programs, utilities, presentation software, databases, and many others. With few exceptions, these applications belong to one of two general classes of Windows applications: single-document interface (SDI) and multiple-document interface (MDI). Your choice depends on whether your application must display multiple views of data simultaneously.
An SDI application consists of one single screen or a series of single screens (see fig. 34.8). Such applications are typically simple and do not require that the user have multiple views of information simultaneously. Before choosing to create an SDI application, you should carefully consider whether your application will ever require the add functionality of an MDI application.
Notepad is a typical SDI application.
By its very definition, an SDI application consists of a single screen or at most a small number of screens (displayed one at a time). Although you can create an SDI application that displays multiple screens simultaneously, you usually should not. The more forms that appear on the screen, the more the user has to think about what he or she is supposed to do and be looking at. Have you ever run several applications simultaneously and got into trouble because they were all jumbled together? Two of the displayed screens might belong to the same application, but the user might have no easy way of knowing that. In any case, an excellent method exists for avoiding such problems: When your application must display multiple forms at the same time, make it an MDI application.
An MDI application consists of one main screen that serves as a container for all the screens belonging to the application. Within this container, an application can simultaneously show different views of data. Word for Windows and Excel are both MDI applications (see fig. 34.9).
Word for Windows 6.0 is an MDI application.
Figure 34.9 includes many screen elements that make up an MDI application. The toolbar at the top contains icons that represent frequently used functions that the user can access without using the application’s menus. To make the toolbar always visible, you place it on the application’s MDI form.
Another screen element is the status bar at the bottom of the screen. Status bars contain a wide variety of information including the time and date, comments about the current control, and the last action.
The choice of MDI versus SDI can be controversial. Programmers on both sides of this issue have very definite, valid opinions. This section has mentioned reasons for leaning toward MDI applications. But always be careful to keep your client’s needs in mind when making your decisions about the features that you want to use. Arguments about whether MDI is better than SDI do not solve the client’s problems. Remember, you must always base your decisions on your client’s or employer’s needs.
Your code must be readable not only to you but also to others. If another programmer cannot read your code, he or she must waste precious time figuring out exactly what the program does and how. Readable code becomes very important when someone has to modify your code. No matter how perfectly you write your code, eventually user requirements will change and your code must change as well. Those who have to modify your code will be grateful for the effort you make to ensure that they can read your code.
Visual Basic enables you to write code with numeric values to specify how an object should behave. This capability makes writing code easier, but make reading the code harder afterwards. The solution is to use global constants that represent these values. Code that uses constants is much easier to read.
Visual Basic 3.0 shipped with a CONSTANT.TXT file that contained the global constants. To use these constants, you only had to add this file to your project. Therefore, you had to load all global constants to your projects whether you needed them or not. The only other solution was to add constants selectively to your projects.
You no longer have to add a CONSTANT.TXT file to your Visual Basic projects. Microsoft included global constants in the support files, so you no longer have to add the constant file to use the constants. Although you can use the older constant files, you should convert your projects to use the new constants and keep up with changes in Visual Basic.
Some programmers are proud that they can read code without the help of constants. Unfortunately, not all programmers are capable of doing so, including some who may need to read your code. By using the Visual Basic global constants, you make your code more readable to all programmers, even those who cannot read code as easily. Even if you are capable of reading code without constants, using constants still makes your code easier to read, especially if you tend to forget what you have done and why. For example, which of the following code lines is more readily understandable:
When you read code that uses the constants, you do not have to remember what each value means. The code is more readable.
Writing commented code is a pain, but reading uncommented code, even code that you wrote just yesterday, can be an even greater pain. Trying to figure out the logic of the code on screen is time consuming. Taking the time to put in comments, on the other hand, saves you time in the long run. Imagine trying to read and understand the meaning and use of the code in listing 34.1 without the comments.
Listing 34.1 Code from 34List01.BAS, a Program That Searches the Tag Property of Each Control and Displays the Appropriate Database Field Information in Each Control.
Listing 34.1 contains the subroutine LoadFormData. You could reference this subroutine in the load event of any form. Simply provide the name of the dynaset containing the data, position the table at the appropriate record, place the names of the fields that you want in the appropriate control’s tag property, and run this routine. In instances where you cannot use Bound controls, this routine works amazing well. Notice that the use of vbHourGlass and vbDefault makes it clear what the program is doing to the mousepointer.
An application’s appearance is as important as what the application does. A poorly thought-out application interface detracts from the application’s usefulness because users focus on the bad interface rather than what it does. Be careful how you use 3-D graphics and how you position controls on your screens. Also be careful to ensure that the user knows what is going on and doesn’t see a mouse pointer during processing. All of these are elements of a user-friendly interface.
To find information on related topics, see the following chapters:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
