What Is an Object?

Directives

14.1 Give forms a consistent appearance and behavior.

Forms are the building blocks of a program's interface; if an application has a user interface, it has at least one form. Although forms are very common, many developers design them poorly. When you add a new form to a project, Visual Basic creates an empty form using a template. Usually the properties of the new form are inappropriate for the type of form you want to create. By following the practical applications listed in this directive, you'll create better forms.

Practical Applications
14.1.1 Assign the proper border style to every form.

When you add a new form to a project, Visual Basic automatically sets the form's FormBorderStyle property to Sizable. More often than not, this setting is inappropriate. If a form doesn't resize its contents when the form's size is changed, chances are the border should not be sizable. Forms are regularly used to create dialog boxes windows that gather information from the user. Such dialog boxes aren't supposed to have resizable borders. The following sections describe the possible values for FormBorderStyle and give recommendations for when to use each value.

FixedDialog

When FormBorderStyle is set to FixedDialog, the form has a solid border that can't be resized. (See Figure 14-1.) This is the most common border style for forms. A form with fixed borders can (and should) have a title bar and can have a control menu box. Unlike in previous editions of Visual Basic, in Visual Basic .NET, you can assign a Minimize button and a Maximize button to a form that uses FixedDialog. You should avoid providing a Maximize button on a form that uses FixedDialog; if you're not letting the user change the size of the form by dragging a border, it doesn't make sense to let the user enlarge the form with a Maximize button. However, sometimes the Minimize button is desirable. For instance, you might want to create a palette dialog box from which users can select a color or create their own, and you might decide to let users minimize the dialog box when they're not using it. When the dialog box is minimized rather than closed, all selections in the dialog box persist. When users restore the dialog box, all changes made previously, such as defining a custom color, remain just as they were left.

Figure 14-1. A form with its FormBorderStyle property set to FixedDialog makes an excellent dialog box. Such forms cannot be resized.

graphics/f14ln01.jpg

None

In general, every form should have a border. When a form doesn't have a border, it also lacks a title bar and a control menu box. As a result, a form without a border can't be moved, resized, or closed without special code. (See Figure 14-2.) Such deviation from standard behavior frustrates users. Most users run multiple applications at the same time after all, this is a big reason to use Windows in the first place and not having the ability to move a form out of the way of another program is more than a bit annoying. Unless you have an incredibly good reason to do otherwise, give all forms borders.

Figure 14-2. Forms without borders violate good design principles. The valid occasions for using such forms are rare.

graphics/f14ln02.jpg

FixedSingle

A form with FormBorderStyle set to FixedSingle has the same border as forms with FormBorderStyle set to FixedDialog. (See Figure 14-3.) The only real difference is that a form that uses FixedSingle has a control box. If you want to provide a control box, use FixedSingle. If not, use FixedDialog.

Figure 14-3. A form with FormBorderStyle set to FixedSingle has a control menu box, unlike forms that use FixedDialog.

graphics/f14ln03.jpg

Sizable

Setting FormBorderStyle to Sizable creates a form with borders that the user can drag to change the size of the form. (See Figure 14-4.) This is the default style for new forms. In general, sizable borders should be applied only to forms that resize their contents to match the new size designated by the user. (I'll discuss later in this chapter how to use Visual Basic. NET's new anchoring features to create "smart forms" that adjust their contents.)

It might be argued that using sizable borders even for a form that doesn't resize its contents is a good idea because it allows the user to force the form to take up less screen real estate, thereby letting the user get a better view of other screen elements. However, when you size a form smaller than the area needed to display its contents, you drastically reduce the form's effectiveness. (Likewise, if a user sizes a form larger than necessary and it doesn't resize its contents, you end up with a large gray area and a puzzled user. See Figure 14-5.) If you think a user will need to make a form smaller, consider making its border FixedSingle and giving the form a Minimize button. Figure 14-6 shows the same enlarged form shown in Figure 14-5, but notice how the contents have scaled themselves to make use of the new real estate. I'll discuss how to do this later in the chapter.

Figure 14-4. The pointer changes when moved over the border of a sizable form. The user can then drag the border to change the size of the form.

graphics/f14ln04.jpg

Figure 14-5. If you let a user resize a form that doesn't adjust its contents accordingly, results that confuse the user can occur.

graphics/f14ln05.jpg

Figure 14-6. If a user resizes a form, the form should resize its contents.

graphics/f14ln06.jpg

FixedToolWindow and SizableToolWindow

The FixedToolWindow and SizableToolWindow styles are unique, and you don't often run across forms that use these styles. Tool windows are generally small dialog boxes that float over the main window of a program. Tool windows usually host tools or actions that can be applied to the main window. For instance, Visual Studio .NET allows you to open a number of windows (such as the Watch window and the Output window) that float over the program's main window. (See Figure 14-7.) Tool windows have thinner title bars and smaller title bar text than ordinary windows. The border of a tool window can be fixed or sizable.

Consider making a form a tool window if it meets the requirements below. (Note that a form meeting these requirements shouldn't necessarily be a tool window. But, if a form doesn't meet these requirements it's almost certainly not a good candidate for a tool window.)

  • The form floats over a main form.

  • The form is never displayed modally.

  • The form contains tools or actions that affect the main form.

Tip

A form shouldn't be made a tool window arbitrarily, nor should a tool window be used to save screen real estate. The difference in height between a standard title bar and a tool window title bar is too small to make much of a difference.


 

Figure 14-7. Visual Studio .NET has many tool windows that float above the main window, providing quick and easy access to various functions.

graphics/f14ln07.jpg

Incorrect:
Figure 14-8. This form doesn't resize its contents, so it should not have a sizable border. Also, it's not a floating tool window and therefore should not have a tool window title bar.

graphics/f14ln08.jpg

Correct:
Figure 14-9. Because this form doesn't resize its contents and is discarded when the user is finished with it, it's considered a dialog box and therefore has a fixed border.

graphics/f14ln09.jpg

Fixed3D

The last value for FormBorderStyle is Fixed3D. This is a rather odd setting. It's pretty much the same as FixedSingle except that the client area has a sunken appearance. (See Figure 14-10.) I can't think of a specific reason to use this style in place of FixedSingle, but it's available if you want it.

Figure 14-10. The FormBorderStyle of Fixed3D is essentially the same as FixedSingle with a sunken client area.

graphics/f14ln10.jpg

14.1.2 Give every form an intelligent and consistent startup position.

The position you choose for your forms is important for many reasons. If a form doesn't appear in an expected position, the user might not even realize that it's displayed. This can easily occur if the user has multiple forms open. Also, if the user's display size is smaller than the display size of the computer used to create the project, it's possible that the form will appear off the screen!

When a form is first displayed, its position is determined by the value of its StartPosition property. The StartPosition property has five possible values: Manual, CenterParent, CenterScreen, WindowsDefaultLocation, and WindowsDefaultBounds.

When a form has its StartPosition set to Manual, its Location property determines where the form appears. This is usually the least desirable of the five options.

The WindowsDefaultLocation value is actually a throwback to earlier days of Windows programming, and it's the default value of the StartPosition property of all new forms. Forms with this setting appear positioned in the upper left corner of the screen, as shown in Figure 14-11. This is an acceptable, but usually not ideal, location.

Figure 14-11. Forms with StartPosition set to WindowsDefaultLocation display in the upper left corner.

graphics/f14ln11.jpg

A form having WindowsDefaultBounds as its StartPosition appears in the upper-left corner. In addition, Windows automatically resizes the form to a default size. (See Figure 14-12.) This means you really don't have control over the initial size of the form. You might find this setting useful, but the CenterParent and CenterScreen values are usually your best choices.

Figure 14-12. Windows chooses the size of the form when its StartPosition is set to WindowsDefaultBounds.

graphics/f14ln12.jpg

When a form's StartPosition property is set to CenterScreen, the form is displayed dead center on the user's screen, regardless of the screen resolution in effect. Also, when a form's StartPosition property is set to CenterParent, the form appears centered on top of its owner form. You designate a form's owner when invoking its ShowDialog method, like this:

LoginForm.ShowDialog(Me) 

You can use any valid form reference in place of Me, or you can omit the owner assignment altogether. If you don't indicate a specific form as the owner, the form is shown in the default Windows position. The best approach is to set the first loaded form in your program to CenterScreen and all of the other forms to CenterParent unless you have a very specific reason to do otherwise. That way, subsequent forms appear centered over their owner forms, regardless of where the owners are located. (See Figure 14-13.) Remember: users can drag your forms around even to different monitors!

Figure 14-13. To make a form appear centered over another form, set the form's StartPosition property to CenterParent and assign the bottom form as the centered form's owner.

graphics/f14ln13.jpg

When displaying a critical dialog box, such as a notification that the printer has run out of paper, display the dialog box centered on the screen so that the user will be more likely to notice it right away.

14.1.3 Don't create morphing forms.

Morphing forms are forms that drastically change their appearance in response to some condition. Usually, the condition that causes the change is not obvious to the user, who is left completely befuddled. Imagine sitting in your living room watching television. You pop into the kitchen to have a snack. When you come back, the living room is full of different furniture, has different carpeting, and is painted a different color. You'd be confused, right? This is exactly how a user feels when you start mucking with the appearance of a form.

When you're presenting a lot of information (or sets of information) to the user, consider using multiple specialized forms. If you need to present the information on a single form, use an advanced interface technique, such as:

  • Tab controls to present categorized information.

  • Tree view controls to present hierarchical lists. When the user selects a node, you can change the contents of an associated container control, such as a frame.

  • A Microsoft Outlook style navigation bar to present icons representing distinct items to view. When the user clicks an icon, you can change the contents of an associated container control.

These aren't the only ways of presenting complicated data, but they give you a starting point. A form should behave much like a room in a house. In your house, a bathroom has one purpose and the kitchen another. Don't create a form that attempts to perform multiple duties; it will probably end up performing all of them less than adequately.

14.1.4 Make forms "smart" so that they resize their contents when the user resizes the form.

Earlier in this chapter, I advocated that you not set a form's border style to sizable unless the form's contents automatically resize with the form. In the past, implementing such behavior required either tedious and often complex code placed in a form's Resize event or a third-party resizing component. The new Windows Forms engine of Visual Basic .NET includes inherent functionality for creating these "smart" forms. Many third-party components accomplish the job of resizing controls on a form, but most have their quirks and issues. I'm happy to say that the new Visual Basic .NET features accomplish this task amazingly well and using them pretty much consists of setting one or both of the following properties for a control:

  • Anchor

    Allows you to specify one or more edges of the container to which the control is anchored

  • Dock

    Allows you to specify an edge of the container to which the control is docked

Note

The container doesn't have to be a form it could be another control such as a panel but for the sake of this discussion, I'll stick to using a form in the examples.


 

Anchoring controls

By default, when a form is resized, a control will maintain its position relative to the top and left edges of the form. (It's anchored in relation to the edges of the container specified by the Anchor property.) This occurs because the default behavior is that controls are anchored to the upper-left corners of their containers. Refer back to Figure 14-8 (on page 289), and notice that even with the form stretched beyond its default size, all of its controls remain exactly where they were originally placed they've maintained their position relative to the top and left edges of the form. The desired behavior would be for the form's contents to adjust to make use of all the available surface space created by enlarging the form. To do this, you change the values of the Anchor properties of the controls on the form.

The Anchor property is unique in how it's set. Figure 14-14 shows what the Anchor property looks like in the Properties window. The gray rectangle in the center of the drop-down represents the control itself. Notice that there are four smaller rectangles one on each side of the larger one. Each of these rectangles represents an anchor to an edge of the control's container. For example, if the top rectangle is selected (which is indicated by it being solid gray), the top of the control is anchored to the top edge of the container. Likewise, if the bottom rectangle is selected, the bottom of the control is anchored to the bottom edge of the container.

By choosing one or more of the four anchoring positions, you can control both the location and the size of the control. This is most easily understood visually. Figures 14-15 through 14-20 illustrate many of the possible settings. Figure 14-15 shows the original form, and each figure after that illustrates the behavior of the Anchor property when the form is enlarged at run time. Although I show only scenarios in which the user enlarges a form, be aware that anchoring affects controls when a user shrinks a form as well.

Figure 14-14. The Anchor property has a special interface for changing its value.

graphics/f14ln14.jpg

Figure 14-15. New controls default to being anchored to the top and left of their container.

graphics/f14ln15.jpg

Figure 14-16. When a control is docked to the top and left edge, it maintains its position and size when the form is scaled.

graphics/f14ln16.jpg

Figure 14-17. Notice that anchoring to the right side anchors the right side of the control to the right edge of the screen.

graphics/f14ln17.jpg

Figure 14-18. If you don't anchor the top and bottom or the left and right in combination, the control moves when the form sizes.

graphics/f14ln18.jpg

Figure 14-19. Anchoring all four sides of a control causes the control to scale in proportion to the change in the size of the container.

graphics/f14ln19.jpg

Figure 14-20. When no edges are anchored, the control's position adjusts in proportion to the change of its container, while its size remains constant.

graphics/f14ln20.jpg

Figure 14-21 shows the same form displayed in Figure 14-9 (on page 290), but it's been sized larger. Notice that the form has adjusted its size accordingly. This amazing effect was accomplished merely by appropriately setting the Anchor property of each control. The image to the left has been tiled because it is no longer large enough to fit the picture box in which it's placed. This might or might not be a problem in a given situation, but you'll need to test your forms for unexpected behavior such as this.

Figure 14-21. By setting a few property values, you can create "smart" forms that resize their contents like this one.

graphics/f14ln21.jpg

Docking controls

In addition to anchoring a control to one or more edges of its container, you also have the option to dock a control. Note, however, that if you set a value other than None for a control's Dock property, its Anchor property is ignored. Docking a control to an edge of its container ensures that the control always stays attached to the edge to which it's docked, and the docked edge is sized to fit the container. Although this is similar to anchoring, there is one important difference: controls are docked in order of their z-order. This means that one docked control will never overlap another docked control. Figure 14-22 shows the drop-down used for setting the Dock property of a control. The rectangle you click determines the docking position of the control. If you select the rectangle in the center, the control will fill the container.

Figure 14-22. Click the rectangle that sits against the edge to which you want to dock the control.

graphics/f14ln22.jpg

A docked control doesn't have to be docked exactly at the edge of its container. Each container contains a DockPadding property, which determines how many pixels away from an edge a docked control is situated. Notice in Figure 14-23 that the tree view control is docked to the left side of the form, but that neither its left, top, nor bottom are flush with the form's edges because of the dock padding values.

You can have a mixture of docked and anchored controls within the same container. Which option you choose for a control anchoring or docking will depend on the situation at hand.

Figure 14-23. You can control the padding of each side of a container independent of its other sides.

graphics/f14ln23.jpg

14.2 Present controls with a standard appearance.

Many programs are data-centric applications and therefore contain lots of text boxes, combo boxes, and label controls. You should follow a number of guidelines when presenting these elements in an interface.

Practical Applications
14.2.1 Show dates and times using the user's regional settings.

It's fairly obvious that users across cultures have a high probability of using different date formats. Even if you plan on distributing your application to only a single culture, you still run the risk of users having different formats because they have customized their regional settings. For example, a Windows XP user can use the Customize Regional Options dialog box shown in Figure 14-24 to change the date format.

Figure 14-24. Users can customize their regional formats you can't make an assumption about a user's format.

graphics/f14ln24.jpg

To compensate for the inability to assume a date format, you should display all dates and times using the appropriate system format. Although it's not obvious, there is an easy way to accomplish this. The DateTime structure has an overloaded method of ToString that allows you to specify a format string. Table 14-1 lists the available date and time format strings and their U.S. culture default strings. Remember, these are the defaults a user can override these formats at any time.

 

Table 14-1. Date and Time Format Strings and Their U.S. Default Values

String

Default U.S. Format

D

7/22/2002

D

Monday, July 22, 2002

T

7:30:15 PM

F

Monday, July 22, 2002 7:30 PM

R

Mon, 22 July 2002 7:30:15 GMT

S

2002-07-22T07:30:15

U

2002-07-22 07:30:15Z

M

July 22

Y

July, 2002

 

To display a date or a time with the system format, use the DateTime class to format the value like this:

txtBirthday.Text = DateTime.Parse("7/22/2004").ToString("D") 

If you always format dates and times using the regional settings, users will always see the values in their chosen formats.

14.2.2 Place labels at the proper vertical location in relation to the controls with which they coincide.

Watch out when you place label controls next to other controls such as text boxes and combo boxes. Often, the top of a label isn't properly set according to the top of the control to which it's related. In addition, label text is often given incorrect justification. Figure 14-25 shows a form with all of these issues. I'm sure you don't create forms as bad as this, but the form illustrates the problem.

Figure 14-25. Properly aligning a label next to its corresponding control and justifying the text to the left makes for a cleaner interface.

graphics/f14ln25.jpg

The easiest way to align a label with a control such as a text box or a combo box is to set the label's Top and Height properties to match its associated text box and then change the label's TextAlign property to MiddleLeft. For controls that are taller than a text box, set the height of the label to the height of a standard text box (20 pixels), align the top of the label with the associated control, and use the MiddleLeft value for the label's TextAlign property. If the label spans multiple lines (something to avoid in general), you'll have to make minor adjustments to the top of the label to get the proper spacing.

Note

Every label caption should end with a colon (:). Check boxes and radio buttons display text as well, but don't confuse these with label controls. The text of a check box or a radio button should never end with a colon.


 

14.2.3 Disable items when they aren't available rather than hide them.

Practical Application 14.1.3 discusses morphing forms. (A morphing form alters its appearance in a drastic and not obvious way in response to an often-unrealized event.) Even if you don't intentionally create morphing forms, it's possible to inadvertently create minor morphing forms. One way to do this is by hiding items when they're not available instead of disabling them.

Most controls that can be placed on a form, as well as individual menu items, have Enabled and Visible properties. When you create minor morphing forms by hiding controls (that is, by setting their Visible properties to False) rather than disabling them when they're unavailable, you create an environment that is difficult for users to deal with. A user can't always relate to the fact that a minute ago a menu item existed but now it's gone, or that since yesterday a form's text box for an address line has disappeared.

Another serious offense is hiding buttons when they're temporarily unavailable. For instance, say that you have a Print button on a form, and before a user can print he must specify a file name in a text box on the form. When the text box is empty, you don't want the user to be able to click the Print button. You could (and should) place code in the button's Click event to display a message to the user if he tries to print without specifying a valid file name. However, this shouldn't be the first line of defense against such an action.

If the user isn't supposed to click a button, the user shouldn't be allowed to click it. However, hiding a button is the wrong means to this end. A user might not grasp the idea that the button will appear (magically, it seems) when he enters a file name. He'll only be confused by the seeming lack of a print option. Disabling the Print button is the preferred method. When a button is disabled, users realize that the function is present but unavailable. Most users are able to further reason that the current environment is preventing them from printing for some reason and that most likely some action on their part will enable the functionality.

Incorrect:
Figure 14-26. Where, O where, has my Print button gone?

graphics/f14ln26.jpg

Correct:
Figure 14-27. Instead of hiding the Print button from the user, simply disable it to show that the function isn't applicable at the moment.

graphics/f14ln27.jpg

14.2.4 Always confirm password changes.

If your application has an interface that allows the user to enter or change a password, always have the user enter the password twice. It's easy to enter a password incorrectly when all you see are asterisks or some other token character. By forcing the user to enter a password twice and comparing the two entries, you'll catch most typing errors and prevent the user from being locked out of something by saving an incorrect password. A perfect example of this is the User Accounts dialog box of Windows XP. (See Figure 14-28.) Notice that the user is required to enter the password twice. Windows XP even goes so far as to allow you to enter text to be used as a hint if you forget your password a great idea.

Figure 14-28. Always force a user to enter changes to a password twice.

graphics/f14ln28.jpg

14.2.5 Use Tag properties judiciously (if at all).

Inexperienced programmers and experienced programmers looking for shortcuts often abuse the Tag property. Almost every control has a Tag property, which is nothing more than an Object property that has no intrinsic functional link with the control to which it belongs. Rather, the Tag property is available for developers to use as an extra property in any way they see fit. Now that the Tag property holds any object (not just string data as in previous versions of Visual Basic), there are more valid cases for using Tag. However, most cases are still better handled with variables in code.

Using Tag properties is often cumbersome for developers and almost always confusing to others reading the code. For example, a number of tricks-and-tips articles show nifty little routines that allow you to stuff delimited information into a Tag property, thereby allowing you to store multiple pieces of information in a single Tag. To extract a given piece of information, you must pass the value of a Tag property through a routine that parses the string and returns the desired piece of information. This is hardly intuitive. (If you must do this, use a structure instead.) Another negative aspect of Tag properties is that they behave much like global variables in that they have global scope, they can be changed by any piece of code within the application, and they don't support any form of data validation. Chapter 5, "Variables," discusses the evils of global variables, and many of the problems described there are inherent in the Tag property.

I wish I could tell you never to use the Tag property, but that just isn't practical. However, be judicious in your use of it. More than likely, there's a better approach to the problem. If you're going to let others see your code, consider the complexity involved with deciphering Tag-referenced code. Just because you can use a Tag property doesn't mean you should. If you must use this property, give a clear and concise comment on what you're doing at every reference to the Tag property. Never assume that a reader will know what your code is doing or what you're storing in a Tag property. If you're accomplishing something particularly complex with a Tag property (and you've chosen not to take a different approach), consider writing a few paragraphs of explanatory text in the Declarations section of a module. Then, at each Tag reference, point the user to the location of the information.

Incorrect:
Private Sub cmdPrint_Click(ByVal sender As System.Object, _                            ByVal As System.EventArgs) _                            Handles cmdPrint.Click    ' Purpose   :  Print the current purchase order.     Try        ' Prevent reentrancy while printing.        If cmdPrint.Tag = "InClick" Then Exit Sub       cmdPrint.Tag = "InClick"       ' Print the purchase order.        Call PrintPurchaseOrder()       ' Clear the flag that indicates we're in here.       cmdPrint.Tag = ""    Catch ex As Exception       ' Handle any exceptions.       ' Clear the flag that indicates we're in here.       cmdPrint.Tag = ""    Finally        ' Don't clear the reentrancy flag here because       ' Finally is called even with Exit Sub     End Try  End Sub 
Correct:
Private Sub cmdPrint_Click(ByVal sender As System.Object, _                            ByVal As System.EventArgs) _                            Handles cmdPrint.Click    ' Purpose   :  Print the current purchase order.     Static s_blnInHere As Boolean    Try        ' Prevent reentrancy while printing.        If s_blnInHere Then Exit Sub       s_blnInHere = True        ' Print the purchase order.        Call PrintPurchaseOrder()       ' Clear the flag that indicates we're in here.       s_blnInHere = False    Catch ex As Exception       ' Handle any exceptions.       ' Clear the flag that indicates we're in here.       s_blnInHere = False    Finally        ' Don't clear the reentrancy flag here because       ' Finally is called even with Exit Sub     End Try End Sub 

14.3 Use the best interface component for a given situation.

I know: that's a pretty obvious-sounding directive. Still, although selecting a control for use on a form seems easy or trivial, many developers choose poorly. Each of the standard controls in the Visual Basic toolbox is designed for a specific purpose. When you mistakenly use one control where you should use another, your interface becomes frail at its core. It's hard to build a solid house when the foundation is weak. Knowing which control works best in a particular situation is the first step to building a solid interface.

Practical Applications
14.3.1 Use a text box control to display editable text.

The text box, perhaps the most common of all controls, excels at displaying text that the user can edit. The text box can display small amounts or large amounts of text. The text box can even add its own scroll bars for lengthy text. If you're displaying text that the user can't edit, the text box might not be the best choice. Text boxes have a fair number of features. In the world of controls, more features frequently means more overhead (resources consumed). A label control, whose sole purpose is to display text that can't be edited, doesn't have the extensive functionality of a text box and therefore uses fewer resources.

In complex situations in which you have a number of pieces of text that the user can edit (text boxes) and you have one or more pieces of text for display only, you might consider using text boxes for all the pieces of text. While you can set the properties of a label control so that it looks similar to a text box, the label control will never be a perfect match. Figure 14-29 shows a text box and two label controls. If you look closely, you'll notice that the label controls display their text up and to the left compared to where the text box displays its text. Although this difference is small, it's a difference nonetheless. An even bigger problem is that the 3D effect for label controls is different from that of text boxes, which you can clearly see in the figure. If you have a number of static pieces of text and can get away with making them all labels, do so. If you have to mix static and editable text and all the text must look the same, you're better off using all text boxes.

Figure 14-29. Labels and text boxes can be set to appear very similar but not exactly the same.

graphics/f14ln29.jpg

14.3.2 Use radio buttons to display static lists of five or fewer items.

Radio buttons are good for letting a user select an item from a very small list. Radio buttons are so named because their behavior closely mimics that of the mechanical buttons on old AM/FM radios. The buttons, usually located along the bottom of the frequency display, allowed the user to select a preset station by pushing its corresponding button. Only one button could be selected at a time, and pushing a button caused the previously selected button to pop out. Radio buttons allow the user to see all available options at one time and quickly choose among them. (Refer back to Figure 14-27.)

Radio buttons work only with small lists because of the amount of screen real estate needed to display the options. Radio buttons should be reserved for static lists because dynamic lists have the effect of creating morphing forms when the radio button text (and thus the physical appearance of the form) changes. If you need to display dynamic lists or lists with more than five items, use a combo box, a list box, or a list view.

If you place a container control on a form and then place several radio buttons in the container, only one of the buttons in the container can be selected at a time. (The buttons are said to be mutually exclusive to their container.) Two radio buttons can be selected at the same time as long as they are in different containers. The group box control is the best choice of container when you want to create independent sets of radio buttons because it uses fewer resources than other alternatives, such as the picture box control.

Writing code to determine which radio button a user has selected can be a hassle. Although you can do this in many ways, the best (and most clever) approach I've found is to use a Select Case statement like this:

Select Case True    Case Is = optAllInfo.Checked    Case Is = optNoTotals.Checked    Case Is = optNoLineItems.Checked End Select 
14.3.3 Use a list box to display single-column dynamic lists and single-column static lists with more than five items when space isn't a concern or the user needs to see many values quickly.

The list box control excels at displaying large single-column lists, allowing the user to view many items simultaneously without user intervention (such as opening a drop down combo box). In addition, the list box can be set to allow the user to select multiple items simultaneously. (See Figure 14-30.)

Figure 14-30. Multiselection list boxes with check marks to denote selection are a great user interface tool.

graphics/f14ln30.jpg

14.3.4 Use the list view to display multicolumn lists and to display lists with informative icons.

The standard list box is a great user-interface element, but its functionality goes only so far. In particular, it has two primary limitations: the inability to display multiple columns of data and the fact that you cannot display small icons next to the list items. The list view control, on the other hand, does these things and more it's like a list box on steroids. For example, the list view control can display grid lines, automatically arrange its items, and let users reorder columns. Figure 14-31 shows a list view control with icons and multiple columns of data. When you need or want to create feature-rich lists, the list view control is your best choice.

Figure 14-31. The list view allows you to display icons and multiple columns of data.

graphics/f14ln31.jpg

14.3.5 Use a combo box to display dynamic lists and static lists with more than five items.

The combo box is perhaps the best all-around control for letting users select items from a list. Although the combo box allows the user to select an item from both short and long lists, the amount of screen real estate required remains the same (when using the standard combo box styles).

Note

The combo box can be displayed in one of two ways, depending on the value of its DropDownStyle property. (See Figure 14-32.) The preferred way is achieved with a DropDownStyle of DropDown or DropDownList (which is the same as DropDown but requires a selection with the mouse it doesn't accept text entry). Although the combo box still supports the Simple style, this style is generally considered antiquated, and you should avoid using it in your interfaces.


 

Figure 14-32. Combo boxes can be either standard (drop-down style) or simple. You should avoid using the simple combo box in your programs.

graphics/f14ln32.jpg

Unless screen real estate is particularly sparse, consider using a set of radio buttons for static lists of five items or fewer. For static lists of two or three items, it's definitely best to use a set of radio buttons.

14.3.6 Display hierarchical data in a tree view control.

When you need to show hierarchical information, such as a list of folders, there is no better control than the tree view control. (See Figure 14-33.) The tree view allows you to create complex structures of nodes. Each node is individually programmable, so you can do things such as expand and collapse specific nodes or assign them unique images. The tree view is often used in conjunction with a list view control; when a node is selected in the tree view, corresponding information is displayed in the list view. For an example, you need look no further than the venerable Windows Explorer, shown in Figure 14-34.

Figure 14-33. The tree view control can display complex lists of hierarchical data.

graphics/f14ln33.jpg

Figure 14-34. Windows Explorer is a classic case of a tree view combined with a list view.

graphics/f14ln34.jpg

14.3.7 Use check boxes to let users toggle options in small, static lists.

When allowing users to select and deselect items (such as program options), use check boxes whenever possible. (See Figure 14-35.) Note that unlike option buttons, several check boxes in a group can be selected at the same time. The multiselection list box supports check boxes refer to Figure 14-30 but, in general, a set of dedicated check box controls is better unless the list is quite large or is built from a dynamic list (such as being filled from a database table).

Figure 14-35. Use check boxes to let the user toggle options.

graphics/f14ln35.jpg

14.3.8 Use a picture box control only when absolutely necessary.

Picture box controls consume more resources than many other controls, and they're often used unnecessarily; there's usually a better choice of control than the picture box. For example, a common misuse of the picture box is as a parent or container control. To create independent sets of radio buttons on a form, for instance, you must place each set in a different container control. The picture box is usually the worst choice of container in these cases. If you don't need the unique functionality provided by the picture box control (that is, you don't need to display a picture), you shouldn't consume the additional resources required by a picture box. Often, the simple panel or group box control is the best choice as a parent control.

14.3.9 Use a scroll bar to indicate position and the track bar to indicate a value.

Scroll bars have been around for some time, and they appear just about everywhere but usually as part of another control, such as within combo boxes and list boxes; rarely do you encounter a stand-alone scroll bar control. Scroll bars are good controls for indicating a location, such as the position in a list. To allow the user to input a value, such as a volume setting in a game, use the track bar control. The track bar control can also be used to select from non-numeric yet sequential options. For instance, a game program might have a graphic detail option that can be set to Minimum, Sparse, Average, Busy, or Wow! Since these items form an increasing sequence, a track bar could be used to select among them. However, unless there are more than five such options, using radio buttons is generally a better choice. Figure 14-36 shows a form with both scroll bars and a track bar. Notice how the track bar is used to specify a value, while the scroll bars indicate the position of the visible portion of the image.

Figure 14-36. Use scroll bars to indicate position, track bars to indicate values.

graphics/f14ln36.jpg

14.4 Provide comprehensive and sensible menus.

Although you might rely heavily on your mouse or another pointing device to perform design tasks while in Windows, many Windows users are keyboard users, using a mouse only when absolutely necessary. Data entry people, in particular, never take their hands off the keyboard. Many software companies receive support calls from angry customers because a commonly accessed function is accessible with a mouse only. Menus are the easiest way for a user who relies on the keyboard to navigate your program, and every program you create should make its features easily accessible through logical menus.

Tip

New users of an application often scan the menus before opening a manual. (Heck, most users never open the manual!) When you provide comprehensive menus, you make your program more intuitive and easier to learn and use.


 

Practical Applications
14.4.1 Format and organize menus in a manner consistent with other popular Windows-based applications.

When designing your menus, look at some of the many popular Windows-based applications available and consider the similarities and differences between their menus and yours. Although your application might be quite unique and therefore have very different menus than other applications, there are probably similarities as well. When possible, make items in your application follow the same structure and design as similar items in the other programs. For example, almost every Windows-based program has at least a File menu and a Help menu. The File menu is always the first drop-down menu on a menu bar, and the Help menu is the last you should never deviate from this organization.

Consistent menu organization goes much deeper than the order and presence of top-level menu items, however. If you take a look at a number of popular Windows-based programs (not just Microsoft's), you'll see many consistencies. For instance, if the program supports a New function, the corresponding menu item is always the first item on the File menu; you'll never see it on the Edit menu, for example.

When a menu command is used to display a dialog box in which the user must enter more information before the command can execute, the menu command is followed by an ellipsis ( ). Don't use ellipses for menu commands that execute functions directly. People are accustomed to this convention, and you should oblige them by providing them with this information. It's easy, and there's no reason not to do it.

The tables appearing in the next few pages Table 14-2 through Table 14-8 show the common commands of the most widespread drop-down menus. These tables aren't all-inclusive, but they should help you design great menus. The underlined letter in some of the commands denotes the key that you should assign as the access key. You create access keys by prefacing the desired letter in the menu item's Text property with an ampersand (&), as shown in Figure 14-37.

A number of items in the tables are labeled Disable when appropriate. Most of these are menu commands that perform an action based on an active file (a file that is opened by the user). If the user doesn't have a file open, disable the menu commands by using the Enabled property. Do not hide the menu item by setting its Visible property to False. Also, the items are listed in each table in the order in which they should appear on the menu.

Figure 14-37. Access keys are assigned much like accelerator keys in a label's caption preface the letter with an ampersand.

graphics/f14ln37.jpg

 

Table 14-2. File Menu: Common Commands

Command

Description

New

Creates a new file. (The type of file that is, document, database, and so on is determined by the application.)

Open

Displays the Open Dialog box from which the user can select a file to open.

Close

Closes the active window. (Disable when appropriate.)

Save

Save changes to the current (active) file. (Disable when appropriate.)

Save As

Displays the Save As dialog box so that the user can specify a file name and then saves the current file under that name. (Disable when appropriate.)

Save All

Saves all the currently opened files. (Disable when appropriate.)

Find File

Displays the Find File dialog box with which the user can locate a file.

Page Setup

Displays the Page Setup dialog box. (Disable when appropriate.)

Print Preview

Displays the current file as it will look when printed. (Disable when appropriate.)

Most recently used list

Lists the most frequently accessed files in the order in which they were opened (newest to oldest). Selecting one of these items opens the corresponding file.

Exit

Terminates the application, closing all windows and files. Prompts the user to save changes when appropriate.

 

 

Table 14-3. Edit Menu: Common Commands

Command

Description

Undo

Nullifies the last command performed by the user, restoring the document to the state it was in before the action was performed.

Repeat

Repeats the last command executed by the user.

Cut

Deletes the current selection and moves a copy of it to the Clipboard.

Copy

Copies the current selection to the Clipboard but leaves the selection unaffected.

Paste

Inserts a copy of the contents of the Clipboard at the current insertion point.

Clear

Deletes the current selection but does not move a copy to the Clipboard.

Select All

Selects the entire contents of the active file. This is most applicable in document-centric programs.

Find

Displays the Find dialog box, which the user can use to locate information (traditionally, text).

Replace

Displays the Replace dialog box. The Replace dialog box is often the Find dialog box with a replace feature activated.

 

 

Table 14-4. View Menu: Common Commands

Command

Description

Full Screen

Changes the view to fill the entire screen.

Toolbars

Displays the Toolbars submenu, allowing the user to choose which toolbars to display.

Zoom

Displays the Zoom dialog box. (This is mostly applicable to document-centric programs.)

 

 

Table 14-5. Insert Menu: Common Commands

Command

Description

General application items

Commands specific to the program should be placed at the top of the menu.

File

Displays a variation of the Open dialog box from which the user can select a file to insert at the current insertion point.

Picture

Displays a variation of the Open dialog box from which the user can select a picture file to insert at the current insertion point. Consider having this dialog box contain a clip art viewer.

 

 

Table 14-6. Tools Menu: Common Commands

Command

Description

General application tools

Commands specific to the program should be placed at the top of the menu.

Macro

Displays the Macro dialog box from which users can create and manage macros.

Options

Displays the Options dialog box for the entire program.

 

 

Table 14-7. Window Menu: Common Commands (Mostly Applicable to MDI Applications)

Command

Description

New Window

Opens a new window, displaying the current file within it.

Arrange All

Arranges all currently opened windows in some predetermined format.

Split

Lets the user split the window into two parts.

Window list

Displays a numbered list of all currently opened files. Selecting an item in the list activates the window containing the file.

 

 

Table 14-8. Help Menu: Common Commands

Command

Description

Product Name Help

Displays the Windows Help program for the current application

(Separator bar)

Used to separate the application Help from the rest of the Help commands

Application-specific entries

Includes items such as tutorials, Web links, and customer support information

About product name

Displays a standard About dialog box containing information about the program

 

14.4.2 Assign shortcut keys to frequently used menu items.

A shortcut key (also referred to as an accelerator key or a hot key) is a keyboard combination that causes a menu command to be invoked without the user having to access the menu. Never underestimate the importance that users place on shortcut keys. Chances are you're using some shortcut keys while developing with Visual Basic, and you'd probably be pretty unhappy to find them removed in a future version. I, for one, would be lost without the ability to press F5 to compile and run or Ctrl+F5 to start with a full compile.

Shortcut keys appear on drop-down menus to the right of menu items' captions. (See Figure 14-38.) Shortcut keys are defined by choosing from a predefined list of values for a menu item's Shortcut property in the Properties window.

Figure 14-38. Shortcut keys are usually displayed to the right of menu commands. Pressing the key combination triggers the command, and the menu doesn't even have to be opened.

graphics/f14ln38.jpg

Shortcut keys are key combinations generally consisting of a Ctrl, Shift, or Alt key or some combination thereof being held while pressing a letter or a function key. Shortcut keys can also be function keys without modifiers (such as the shortcut key F7 in Microsoft Word used to run the spelling checker). Of course, the variations are finite, and you'll have to carefully consider how to assign shortcut keys in your program. First consider the basic shortcut keys listed in the Table 14-9, and apply them to your menu items if applicable. Next list the functions accessed by your menu items in the order that you expect them to be most frequently used, and start assigning shortcut keys to the items at the top of the list. Avoid using common shortcut keys found in Table 14-9 for uses different than those listed users are probably accustomed to those keys having meanings other than yours.

Although it's not always possible, try to assign logical key combinations. Obviously, the meaning of, say, F6 is hardly logical, but when assigning modifiers such as Alt with another character you have some flexibility. For instance, the key combination of Ctrl+Q might be a more intuitive shortcut key for Quit Payroll than Ctrl+T.

There are essentially two types of shortcut keys: basic and extended. Basic shortcut keys are suitable in most applications, and you're encouraged to implement as many of them as possible in your programs. Again, if you don't implement a particular basic shortcut key as defined in Table 14-9, don't use the shortcut key for something else in your program; most users are accustomed to these shortcut keys performing these functions.

The extended shortcut keys, shown in Table 14-10, are completely optional, and they correspond to features that you might or might not have in your program. If your program supports a listed feature, you're strongly encouraged to use the associated shortcut key. If not, feel free to use the extended shortcut key in your application as you see fit.

 

Table 14-9. Basic Shortcut Keys 

Shortcut

Menu | Command

Ctrl+N

File | New or its equivalent

Ctrl+O

File | Open

Ctrl+S

File | Save

Ctrl+P

File | Print

Ctrl+Z

Edit | Undo

Ctrl+Y

Edit | Repeat

Ctrl+X

Edit | Cut

Ctrl+C

Edit | Copy

Ctrl+V

Edit | Paste

Delete

Edit | Clear

Ctrl+A

Edit | Select All

F1

Context Help (Note: this is not displayed on the menu.)

 

 

Table 14-10. Extended Shortcut Keys

Shortcut

Menu/Command

Ctrl+W

File | Close (Note: displaying this on the menu is optional.)

Ctrl+Alt+O

View | Outline

Ctrl+D

Format | Font

Ctrl+E

Format | Center align

Ctrl+J

Format | Justify align

Ctrl+L

Format | Left align

Ctrl+R

Format | Right align

F7

Tools | Check Spelling

Shift+F7

Tools | Thesaurus (Note: displaying this on the menu is optional.)

Ctrl+Alt+S

Window | Split

Shift+F1

Context-sensitive Help (Note: do not display this on the menu.)

 

14.4.3 Every toolbar button should have a corresponding menu item.

If a program has a menu (as most programs should), it should also have a toolbar. The actual toolbar items in your program will, of course, depend on the features supported. The following list shows the standard toolbar items found in most Windows programs in the order they should appear from left to right. If you include any of these buttons on your toolbar, display them in this order:

  • New File

  • Open File

  • Save File

  • Print

  • Print Preview

  • Check Spelling

  • Cut

  • Copy

  • Paste

  • Undo

  • Redo

  • Help

Most likely, your program will have other buttons in addition to some or all of these. The place to put these application-specific buttons is to the left of the Help button, which is always the rightmost button on the toolbar, if provided.

14.5 Use system colors wherever possible.

If you've ever changed any of your Windows system colors, such as the active window or inactive title bar colors, you might have been pleasantly surprised to find that certain programs altered their display to match the new color settings. If a program didn't adjust its colors, it should have. You change your system colors by using the Display Properties dialog box accessed by right-clicking the desktop and selecting Properties. Note that Windows XP has a second dialog box available from the Appearance tab that is used to change the colors. (See Figure 14-39.) Windows maintains a set of values for the user-selected colors or chosen color scheme. These values are available to you as a Visual Basic programmer, and you should use them.

Each Windows system color has a specific enumerated value in Visual Basic. The enumeration containing the values is System.Drawing.SystemColors. When you assign a system color value to a color property of an object, the current system color assigned to that constant is used. For example, you could set the color equal to the user's current Control color (gray by default) using a statement such as this:

Me.BackColor = System.Drawing.SystemColors.Control 
Figure 14-39. Users can change their system colors to any colors they see fit.

graphics/f14ln39.jpg

Visual Basic makes it easy to reference system colors at design time by providing you a system color palette in the Properties window. This color palette is accessible from any color property of a selected object. (See Figure 14-40.)

If your program doesn't use system colors, it will stick out like a sore thumb when the user modifies his or her colors. It's also important to note that users don't just change their color settings for aesthetic reasons. I work with a programmer who's color-blind (or so he claims there's a rumor floating around that this has been a running gag on us for about 12 years). He has modified his system colors (and the colors of his Visual Basic code editor as well) so that he can better see things. As I understand it, being color-blind does not necessarily mean that you don't see colors, just that you don't see or distinguish them the same way as a person who isn't color-blind. Certain colors can appear to be the same color, which can make it difficult or impossible to read text or see other information. If you cleverly hard-code color values where system colors should be used, you can actually make using your program difficult or impossible! Using system colors is "playing well with others."

Figure 14-40. You don't have to memorize color values or even enumerated member names because you can select a system colors from the color palette.

graphics/f14ln40.jpg

As I said before, system colors are members of System.Drawing.SystemColors. Table 14-11 lists the system color values and their basic descriptions.

 

Table 14-11. Members of System.Drawing.SystemColors 

Value

Description

ActiveBorder

The color of the active window's border

ActiveCaption

The color of the background of the active window's title bar

ActiveCaptionText

The color of the text in the active window's title bar

AppWorkspace

The color of the application workspace the area in an MDI program that is not being occupied by child windows

Control

The color of the face of 3D elements

ControlDark

The color of the dark shadow of 3D elements

ControlDarkDark

The color of the darkest shadow of 3D elements

ControlLight

The color of the darker highlight of 3D elements

ControlLightLight

The color of the lightest highlight of 3D elements

ControlText

The color of text in a 3D element

Desktop

The color of the desktop

GrayText

The color of disabled or dimmed text

Highlight

The color of the background of selected items

HighlightText

The color of the text of selected items

HotTrack

The color used to designate a hot-tracked item

InactiveBorder

The color of an inactive window's border

InactiveCaption

The color of the background of an inactive window's title bar

InactiveCaptionText

The color of the text in an inactive window's title bar

Info

The color of the background of a ToolTip

InfoText

The color of the text of a ToolTip

Menu

The color of a menu's background

MenuText

The color of a menu's text

ScrollBar

The color of the background of a scroll bar

Window

The color of the background in the client area of a window

WindowFrame

The color of a window frame

WindowText

The color of the text in the client area of a window

 

It's impossible to fully discuss interface design in a single chapter. However, the principles covered here are probably applicable to 99 percent of the applications you'll create. When you follow these guidelines, your programs won't suffer the fate of so many others. You'll have a cleaner, more intuitive, and more efficient interface that allows the user to work in harmony with your application and leverage skills already developed and nurtured.



Practical Standards for Microsoft Visual Basic. NET
Practical Standards for Microsoft Visual Basic .NET (Pro-Developer)
ISBN: 0735613567
EAN: 2147483647
Year: 2005
Pages: 84

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net