[Design Application]
From Windows To Windows CE: Programming Success (Part II)
Mulitple operating-system configurations, user-interface differences, and memory mangement must be considered.
Part I of this two-part series appeared in the May 29 issue, p. 103—ED
Windows CE was designed to accommodate a wide variety of intelligent computing devices. Thus, it's a highly configurable operating system. But, all Windows CE deployments don't include the same OS components. These OS components represent a range of functionality.
In some cases, differences are directly related to hardware. To give one small example, many Windows CE devices have a touch screen, but lack a mouse. The OS on such devices usually includes the cursor component, which supplies support for a simple wait cursor at the center of the screen. But the mcursor component, which provides support for mouse cursors and the associated API, may not be present.
In other cases, an OS configuration might simply not be intended to support certain functionality, like that provided by the CE IE4 browser components. Actually, in some instances the entire Windows GDI may be missing. The component that supplies the GDI, gwes, is by no means necessary to boot Windows CE.
There are various licensing levels for Windows CE. Higher levels, with more components, cost OEMs more money. So, it makes sense that not all components will be present on all devices.
Therefore, you must ask which configuration you will be targeting. That of course depends on your application and intended audience. A large number of applications aim Handheld PC or pocket PC/Palm-size devices. Each comprises a fairly concise environment, and includes the same basic components within the whole family of devices. (The GDI will certainly be there.) Be aware, however, that different HPC and Pocket PC releases may have different support. If you are targeting HPC 2.12 beyond, you can use IE4, for example. But, don't expect your project to build for 2.11 or 2.10, if you decide to also target earlier devices at a later date.
On the other hand, many OEMs manufacture devices that have their own custom configuration of Windows CE. If you're targeting one of these devices, you will need to find out what support is present in the OS and plan accordingly. Also, it's likely that you will have to link to the libraries provided by the OEM for that OS configuration.
The toolkits providing the Handheld PC and Palm-size PC (now Pocket PC) configurations are available at www.msdn.microsoft.com/cetools/default.asp. A new Auto PC SDK, which targets Windows CE configurations for in-car computing devices, has recently been made available from Microsoft. Check it out at www.msdn.microsoft.com/cetools/platform/autopc.asp.
Often, Windows CE devices have small display sizes. For example, the Palm-size PC is 320 by 240pixels, whereas a handheld medical device might have a standard VGA display. To maximize the use of the screen real estate, Windows CE applications usually use a full-screen window, without a title bar or maximize/minimize buttons. Typically, the window also doesn't have a border and isn't sizeable.
The Multiple Document Interface (MDI) is commonly used in desktop applications, but not in Windows CE products. For example, when you open multiple files in Pocket Word, the various documents are displayed in different top-level windows, rather than in the child windows of Word's main window. Because windows are supposed to be full screen in Windows CE, you generally can't plan on using MDI when designing your application.
New Multipurpose Control Another difference is that Windows CE has a new control called CommandBand. This is a compact, efficient visual control that serves multiple purposes, like providing a location for menus, toolbars, and help/close buttons, without consuming too much valuable screen real estate (see the figure).
The Microsoft Developer Network (MSDN) has an article describing how to use the CommandBand control (www.msdn.microsoft.com/library/techart/commandband.htm).
It's especially important to pay attention to details while using the CommandBand control. The CommandBand is a common control, so make sure that you call InitCommonControls Ex() before using it. Plus, it's very common to save the CommandBand settings in the registry when the program exits. This way the CommandBand settings can be restored when the program is next executed. Use the CommandBands_GetRestoreInformation() function to retrieve the settings and write them to the registry.
Additionally, on some Windows CE devices, such as the Palm-size PC, only one instance of an application should be run at a time. Unlike desktop Windows, the hPrevInstance parameter to WinMain() isn't set on Windows CE. So, it cannot be used to check for a running instance of your application. An alternative method is to use a Mutex (Listing 1).
A single-instance application intended to run on a Palm-size PC usually does't have an exit button (the "cross" button on the upper left corner), or an exit command under a menu.
As noted, Windows CE devices also vary in display size. For example, some HPC devices are 480 by 240 pixels, some are 640 by 240 pixels, and Palm-size PCs are 240 by 320 pixels. Because CE applications are supposed to have a full-screen window, it's a good idea to use the CW_USEDEFAULT flag when creating your main window (Listing 2).
Though application windows are full-screen in Windows CE, dialog boxes can be any size. One easy way to deal with the issue of different screen sizes is to make certain that all of the dialog boxes fit in the smallest possible screen size. A better way to handle this is to resize the dialog box at run time (Listing 3)
These techniques will work when the dialog boxes are created in your program, but what if they are from the OS, like the file-open dialog box that you get when you call GetOpenFileName() or GetSaveFileName()? Also, what about all the dialog boxes used by the Control Panel applets?
Reprints
