Chapter 15 -- Choosing Windows Controls

Chapter 15

In Chapter 14, we looked at various ways to structure forms based on how the entities represented in them are related. In this chapter, we'll look at how to match specific controls to certain kinds of logical data.

Two basic principles apply to choosing controls. The most important is to choose the control that best matches the way users think about the data—in other words, to match the users' mental model. Secondarily, you should limit user input to the narrowest possible range of values.

People who work with databases tend to think of data as textual values. If you open a recordset in datasheet view in Microsoft Access, as shown in Figure 15-1, all the fields are shown as text. But in fact only the CustomerName field has a Text data type. CustomerNumber is an AutoNumber field, DateOfFirstOrder is Date/Time, CreditLimit is Currency, and PreferredCustomer is Yes/No (Boolean).

click to view at full size.

Figure 15-1. This datasheet shows several data types as textual values.

When systems designers are manipulating data, we of course think about different data domains and don't try to join a date to a Boolean value. Nevertheless, there is a tendency to display values of different types the same way, usually in text boxes. This approach works—you can display any data type in a text box—but it isn't doing your users any favors. You should consider a text box to be the control of last resort and use it only after you've determined that the other, more specific control types are inapplicable.

Looking at a field declared on the Date/Time domain, you might see a string of characters formatted in a specific way, but users see a date. Their mental process is not at all the same when changing a date as when changing a text string. If a user has mistyped a name, she might think, "The J in 'Jary' needs to be an M." If a user needs to change a date, however, she's more likely to think along the lines of, "Oh, that really should be a week from Monday." You can make users' lives easier by choosing a control that supports the way they think about the data.

You'll also make users' lives easier by limiting the values they can enter. Data limitation isn't the same issue as data validation, which we'll discuss in the next chapter. Data validation is an after-the-fact check performed by the system to ensure that the value entered is reasonable. Data limitation prevents users from entering an unreasonable value in the first place.

The place to start is, of course, limiting the type of data that users can enter. For choosing controls, data can be organized into four groups: logical data, sets of values, numbers and dates, and text. We'll look at each of these in this chapter.

NOTE
It isn't possible for me to discuss the seemingly endless variety of widgets, gizmos, and gadgets available from third-party suppliers as ActiveX controls. I've limited my discussion to those provided by Microsoft Visual Basic and Access. However, I do encourage you to familiarize yourself with what's available. (The Microsoft Web site is a good place to start.) You'll find a lot of junk around, but a lot of seriously cool stuff, too—and you might find that a few hundred dollars spent on a third-party tool can save you weeks of development and testing.



Designing Relational Database Systems
Designing Relational Database Systems (Dv-Mps Designing)
ISBN: 073560634X
EAN: 2147483647
Year: 1999
Pages: 124

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