Categories Programming

Continued from Toolkits

Now let's turn to writing an actual Windows CE application. The steps you take are the same as those for writing an application for desktop versions of Windows. First, you create a new workspace within Visual C++. Although you can use one of the many wizards designed to assist you in creating Windows CE applications, you can also create one manually by selecting Win32 application, and checking off the Windows CE target processors you want (see Figure 1 below).

Once the project is created, you simply write the code and create any resources, including menus, icons, and dialog box templates, almost exactly as you would when writing an application for Windows 98 or Windows NT, with the exception of the aforementioned differences in the API. As we noted earlier, the differences aren't major; nevertheless, a few distinctions in the Windows CE programming model should be noted. First, and on the surface most surprising, top-level windows under Windows CE don't support menus. This doesn't mean that Windows CE applications can't have menus, it's just that they are supported through the command bar control.

The command bar control and its more complex cousin, the command bands control, combine menu and toolbar support as well as a place for application-close and help buttons for Windows CE applications. The controls are designed to be fairly straightforward to program. In fact, a simple command bar that provides a menu and an application-close box takes only three lines of code. The command bands control extends the command bar concept by allowing the components of the command bar, the menu, buttons, and other controls to be separated into separate bands that can be arranged by the user. This control is based on the rebar control developed for Internet Explorer 3.

Another difference with Windows CE applications is that icons are assigned on a class basis within an application, not a window-instance basis, meaning that two windows of the same window class will have the same icon. This doesn't really have much of an impact since a window's icon is displayed only in the taskbar button for the window.

Aside from these issues, most of the other differences have more to do with programming conventions than with programming restrictions or implementation differences. For example, while Windows CE top-level windows can have title bars, by convention they don't. Removing the title bar saves space on the small screens used by Windows CE devices. On the desktop versions of Windows, the title bar is used to drag a window around the screen. This function isn't used often on Windows CE systems since by default, top level windows in Windows CE are all full-screen.

This is a good place to mention one of the new features of Windows CE. Starting with Windows CE 2.1, the window manager supports standard, resizable windows. While the operating system always supported windows of any fixed size, now the window manager supports a sizing border around overlapped windows so that they can be resized by the user. You won't see this used on the new H/PC Pro machines very often, however, since the default is for top-level windows to be full screen, even for these large-screen systems.

FIGURE 2: This code illustrates how similar Windows CE applications are to ordinary Windows apps. (Download the issue archive for this code.)

With these caveats, lets look at a simple Windows CE application. Figure 2 shows source code for the simple TinyCE application that just displays a line of text in its main window. At first glance, Win32 programmers will be hard pressed to notice the subtle differences between this application and a Windows 98 or NT application. The program has the same window-class registration, window creation, message loop, and window procedure as any other Windows application. The differences in the example reflect differences in the API as discussed above, such as the use of a command bar to provide a close box. Once the code is written, you use the exact same techniques to compile and run it as you would with a desktop application. Compiling does include an extra step to download the resulting EXE or DLL automatically to the attached Windows CE device. You can then execute the program on the Windows CE device by selecting the same Program | Run menu item (or Ctrl-F5) as you would to run a Windows NT program under development.

And, yes, you can step through the program using the integrated debugger. The main difference between debugging a Windows CE application and debugging a local Windows NT application is the impact of the speed of the serial link that connects the development PC with the remote Windows CE system. This link makes single-step debugging a slow and painful process. In fact, I tend to use the debugger for only solving the most intractable of bugs.

There are alternatives to using the remote debugger. The platform SDKs for the H/PC, Palm-size PC and Auto PC all include emulator programs that attempt to emulate the remote Windows CE device on Windows NT. This emulator runs a specially compiled version of your application. It emulates the Windows CE API including the extensions such as the database API. The problem with the emulator is that it does not model the Windows CE environment perfectly. There may well be times when, after a day's work, you realize the problem you're chasing is an emulator issue, not a bug in your code.

It's a good idea to create your Windows CE application so it can be compiled for both Windows CE and Windows NT, thus avoiding emulator problems. This approach lets you work on the generic parts of the application locally under Windows NT and, simply by selecting a different target, compile for Windows CE. But if you do this, remember not to stay too long on either platform. If you spend too much time compiling for Windows NT, it may take some work to make the changes for the program to run under Windows CE.

Writing code that will compile for both Windows NT and Windows CE isn't too difficult. For those parts of the code specific to a particular operating system, use compiler defines to have those sections selectively compile for the specific OS. In the code fragment below, the functions for creating a command bar are encapsulated in # conditional compile statements so they will be included only when compiling for Windows CE.

#ifdef _WIN32_WCE // If compiling for CE

HWND hwndCB;

// Create a command bar.

// Add exit button to command bar.

CommandBar_AddAdornments (hwndCB, 0, 0);

#endif //_WIN32_WCE

Of course, writing code is only part of application development. You also need a set of tools to debug and test the application. When you install Visual C++ for Windows CE, a set of remote tools is installed to help you with debugging the Windows CE applications. For the most part, these tools mirror the tools used for desktop Windows debugging. There are Windows CE versions of Regedit, for editing the registry on the Windows CE device; Spy, to monitor messages received by Windows CE windows; and ZoomIn, for examining window pixels. You also get a process monitor that lets you see and monitor the status of the processes running on the device. The status information includes the current threads running in each process as well as the DLLs that process has loaded. A final tool is a memory viewer application that lets you browse the contents of the application's heaps. All of these tools run on the attached desktop PC and communicate with remote client software on the Windows CE device.

FIGURE 1:

You can create a Windows CE application manually in the VC++ environment by selecting Win32 application and checking off the Windows CE target processors you want.

Next: The Platform Builder

Published as PC Tech Feature in the 3/23/99 issue of PC Magazine.

Related Links
• Windows CE dvs. Mini-Notebooks -- PC Labs 2/9/99
• Software to Go: Palm/Windows CE Software -- PC Labs 2/9/99
• PalmPilot Software Awards -- Softwar Library
• Handheld PCs -- ZDProducts
• The Place to Select and Buy Portable PCs -- computershopper.com