A Better Approach to WinCE/Pocket PC Forms
Pick any two.
In the last few installments, we saw how to rapidly and simply move a user interface from Win 32 to Windows CE. The fastest way isn't always the best way, or even an adequate way, though. From my point of view, the place this becomes most glaringly apparent is in the case of form based data entry applications.
On the desktop, dialog box based forms are a good, self-documenting way to collect data from users. For Windows CE devices, because of screen size limitations, most non-trivial dialog based forms must be re-implemented. The "quick and dirty" route to re-implementation is to subdivide a large dialog into a set of tabbed dialog pages.
However, in terms of the user's prior experience, reorganizing one dialog-based form into a series of dialogs representing the same form sets up a subtle contradiction. Tabbed dialogs on the desktop usually imply a collection of related, but independent, information. Using a tabbed dialog to represent a form violates the user's intuition and prior experience about what is expected of her. Should all of the tabs be visited? In order? Is there an obvious way to tell when input is required and when input has been validated? The tabbed dialog has real drawbacks, because in most cases, the information in a form is related and dependent. A first name is meaningless without a last name; a shipping address is not useful without a billing address; and so forth.
Command Bands: The Win CE Forms Solution
Windows CE CommandBands provide the tool for creating intuitive forms that accommodate the limitations of the HPC and PPC, wringing meaning out of every last pixel on the tiny Windows CE screen. The CommandBands approach to form design allows you to retain the visual metaphor of a single form, but in a way that efficiently uses screen resources.
CommandBands controls are related to the CommandBar control. In the MenuBar example in a previous article, we saw that CommandBars act as containers for controls, managing painting, visual changes in the control states, and message routing from the controls to the window procedure. CommandBands build on and extend this concept, by providing a container for CommandBars. This powerful construct will let you create a "form" composed of an aggregation of optionally moveable, resizable CommandBars. Each CommandBar contains one control. To put this another way, the Command Band represents the form as a whole, and the CommandBars represent the individual fields of the form.
This approach overcomes the limitations of the tabbed dialog as a form based data entry interface. First, it allows you to put all of the fields of the form on the screen at once, because the user can resize CommandBands. For example, you can show a few fields at full size, and the rest as "grippers" the user can drag to open the field. Second, it simplifies and rationalizes data validation, because the fields in a form enjoy the unifying relationship established by containment in the CommandBands. And finally, it improves your options if you choose not to let users move and resize the bands containing the fields. In this case, you can create "pages" of bands that users navigate using next / previous controls. This kind of navigation behavior is less prone to confusing the user than the tabbed dialog approach, as well as being more amenable to application specific specialization.
The first example shows how to create and use CommandBands. Creating and using CommandBands entails these steps:
- Create the CommandBands control, setting the overall band style, the base band ID ( the lowest individual band ID in the control ), and optionally, the controls image list
- Allocate and array of REBARBANDINFO structures, one per band.
- Initialize each of the band structures.
- Add the bands.
- Loop through the bands, inserting a control in the CommandBar contained in each band.
- Initialize controls as necessary.