Many graphical user interfaces use a desktop metaphor, which simplifies common file operations by presenting them in a familiar context. Depicting files as paper documents, directories as folders, and deleted items within a trash can are examples of the desktop metaphor. Though appropriate for most applications running on a Handheld PC or similar device, this metaphor may not be appropriate for some embedded systems, such as a car navigation application or a point-of-sale device. If the desktop metaphor is not appropriate for your application, use another familiar metaphor that seems suitable. Virtual reality applications commonly use the room metaphor.
Whatever metaphor you choose, it is important to provide a context or point of reference for your application. When using the desktop metaphor, you can accomplish this by presenting objects in standard windows and dialog boxes. If using a different metaphor, you may choose to forgo using windows entirely, and present objects only in dialog boxes. If you do use windows in your application, they should occupy the full screen, unless your application will be used in conjunction with another application. An online Help system is one example of an application whose windows do not take up the full screen because the user benefits from seeing its windows displayed with another application. If you are creating an application whose windows do not take up the full screen, design the window to be a fixed size, because Windows CE does not support the resizing of windows by users.
Windows CE supports several types of window styles. Some contain borders, while others contain scroll bars. One common window style is WS_OVERLAPPED. This window style displays a window button on the taskbar. This is an important factor to be aware of because users navigate from one open window to another by tapping an application's window button on the taskbar and restore a window by tapping its taskbar button again. An application displays a button on the taskbar only if its primary window contains the WS_OVERLAPPED style. Additionally, when the system is running low on power, it sends the WM_HIBERNATE message to all windows that have a button on the taskbar. If an application does not have a button on the taskbar it cannot receive and respond to this message.
Dialog boxes are secondary windows that contain controls and provide information to the user about actions. Windows CE supports three types of dialog boxes: application-defined dialog boxes, message boxes, and property sheets.
An application-defined dialog box helps users perform tasks specific to an application. They provide a great deal of flexibility by allowing you to place controls directly onto the body of the dialog box. This is especially useful when designing interfaces that do not use a desktop metaphor, for you can design an entire application interface using only application-defined dialog boxes to house controls. When using an application-defined dialog box, include only as many controls as are necessary for your application and space them adequately.
An application-defined dialog box can be modal or modeless. A modal dialog box requires the user to supply information or cancel the dialog box before allowing the application to continue. A modeless dialog box allows the user to supply information and return to a previous task without closing the dialog box.
A message box is a modal dialog box that displays a message and prompts for user input. It typically contains a text message and one or more predefined buttons.
A property sheet is a collection of tabbed dialog boxes that enables a user to view and modify the properties of an object.
In a desktop metaphor, a dialog box typically contains an OK and Cancel command which initiate a user's request or dismiss the window, respectively. In Windows CE, the X button represents both the Close and Cancel commands. Follow these guidelines for using the X and OK buttons in dialog boxes: