. . . . . . Helping users
A key goal of any application that includes a user interface is to make it easy for users to enter the right data. Several VFP 9 features contribute to that goal. The most significant is support for auto-completion in textboxes. In addition, the InputMask and Format properties have some new values, and you have more control over movement of the cursor among controls. Auto-complete text boxes When a field is limited to a particular set of values, it’s not unusual to use a combobox or listbox so the user can’t enter anything else. But in some situations, while the user is likely to choose from among a small set of values most of the time, the actual list is unlimited, so a combo or list isn’t the right choice. In other situations, the user is limited to one list, but will almost always choose from just a few values in that list. Consider an application for a doctor’s office. Most patients are likely to come from a small geographic area, though occasionally a patient may come from much farther away. Choosing from a combo or list for fields like state, zip code, or area code in this situation is likely to be slower than just typing in the desired value. Defining a combo or list to specify the town would be difficult, but it’s likely that most patients come from a handful of towns. These are the situations for which auto-completion was created. This technique tracks a user’s entries in a particular field. When the user returns to that field, she’s offered a list of her most recent or most frequent entries. She can choose from the list or type something new. Internet Explorer is among the applications that supports auto-completion. Figure 12 shows a form with a number of auto-complete textboxes. When you enter an auto-complete textbox, the list of choices appears. You can choose one with either the keyboard or the mouse, or you can start typing. As you type, the list narrows down to those items that match the characters you entered. If you type a new entry, it’s added to the list. You can remove an item from the list by highlighting it and pressing the Delete key. Figure 12. With auto-complete, a list of choices appears when you enter a textbox. Once you start typing, the list narrows down to those items that match what you entered so far.
Not surprisingly, auto-complete data is stored in a table. You can choose whether to put all auto-complete data in a single table, use separate tables for each application or even for each textbox that supports auto-complete within an application. By default, auto-complete data is stored in AutoComp.DBF in the directory specified by HOME(7) (the user application data directory). Table 7 shows the required structure for the auto-complete table; VFP creates the table automatically when it’s needed.
The auto-complete table supports several different ways of organizing the list of items. Those options are echoed in the AutoComplete property that turns this feature on. Table 8 shows the values for AutoComplete. Not surprisingly, when AutoComplete is set to 2, 3, or 4, the list is sorted in descending order, based on the specified field. For AutoComplete values of 2 and 4, the Updated field is used to break ties. You can change the AutoComplete property at run time, so you can offer users the chance to control the order of these items. (The form in Figure 12 does so, but in a production application, you’re more likely to put this choice in an Options dialog.)
If every textbox in an application had its own list for auto-complete, the auto-complete table would grow far too large and, more importantly, users would become frustrated, as an item entered on one form fails to show up for the same field on another form. Fortunately, VFP’s auto-complete feature is designed to avoid this problem. The new AutoCompSource property of textboxes lets you specify a category for the textbox, such as FirstName or City. All textboxes with the same value for AutoCompSource share a single list of items, based on the value of the Source field in the auto-complete table. (You have probably seen this behavior with websites where your name or email address appears in an Auto-complete list for a website you never used before.) In practice, this means that for each application you build, you probably want to subclass your textbox class for each category, setting AutoCompSource appropriately. Then, use your subclasses to build forms with textboxes that share auto-complete data. Alternatively, if you already have a builder for textboxes, you could add AutoCompSource there. You could By default, there’s a single auto-complete table. (As noted above, it’s stored in the directory referenced by HOME(7).) However, you can choose to put the table wherever you want and even to use multiple tables. The AutoCompTable property of the _SCREEN object specifies the default location for the AutoComp table. Set it to specify something other than the default location. Be aware that data is saved to the auto-complete table as soon as the user leaves the control, whether or not the user actually saves the data to the underlying table. The auto-complete table must be an actual table. It can’t be a cursor or view. In addition, textboxes have a new AutoCompTable property that lets you specify where to find the table for that particular textbox. When the property is empty, the textbox uses the table specified by _SCREEN.AutoCompTable. When both are empty, the default table is used.
The Developer Downloads for this chapter, available from www., include the form shown in Figure 12 as EmployeeAdd.SCX. It has Auto-complete enabled for all the textboxes except for the address. There’s no code behind the form for the auto-complete capabilities; a number of properties are set for the various textboxes. The form also includes a combobox that lets you change the auto-complete setting for the textboxes, so the lists appear in a different order. |
|
来自: Alkaid2015 > 《75.VFP狐仙◆》