January 17, 2021
Hot Topics:

Going Mobile: How to Port Your Win32 Code to Windows CE

  • By Nancy Nicolaisen
  • Send Email »
  • More Articles »
Task 1:

Modify the application's main icon so that its dimensions are exactly 16x16 pixels. Since many CE devices are limited in their color depth, check to make sure your icon still "reads" correctly in black and white. ( Most paint programs have a function that let you change a color image to grey scale or black and white. ) Delete the small icon's file and references from the project.


The resource_file application includes no special cursor resources. However, this simply means that the app doesn't store any images specifically intended to be displayed as cursors in it's resource file. Win 32 applications would typically use the APIs LoadCursor, LoadCursorFromFile, or CreateCursor to get or create a special cursor.

In most cases, using special purpose cursors is a bad practice under Win CE, both because it is unnecessarily wasteful of memory and because the concept of a cursor is permeated by the assumption that the user has a keyboard and a mouse as well. By contrast, Windows CE devices are heavily biased toward stylus input. Since the user taps the screen to choose the "current position" (which is really just the location of the input focus) a cursor is superfluous. Most Windows CE devices provide implicit support for the wait cursor, however. Standard practice is to display the wait cursor whenever you undertake an operation that will make the system unresponsive for a noticeable period of time. Here's how to load the native wait cursor:

//LoadCursor loads the cursor image and returns the handle//SetCursor sets the new cursor and returns the handle to //the old cursorhOldCursor = SetCursor(LoadCursor( NULL, IDC_WAIT));

Here's one more thing of note about custom cursor resources. The file that encodes a cursor resource includes information for a variety of display devices. On the desktop, this means the cursor is drawn correctly for all resolution and aspect ratios, so the actual cursor file may be several times as large as the bitmap used for the cursor. Also, Windows CE doesn't support color cursors, and attempting to load one may produce catastrophic results.

Task 2:

Identify code that manipulates the cursor. Except for code that displays the wait cursor during lengthy operations, eliminate calls to cursor handling functions. Where the cursor changes signal change of mode or application state, devise ways to inform users. For example, use message boxes or modify the application's caption on the taskbar icon


Here are the lines from the resource file that encode the default accelerator for the resource_file application:


This entry means a user can type Alt+? To open the application's About box . Much of what was said about cursors applies to accelerators. They are not as wasteful of memory or as risky if misused, but they lose their meaning in an environment where the user has options such as the stylus, voice input and rich ink.

Task 3:

Eliminate code that defines or manipulates accelerators.


Here's the application's string table resource code:

STRINGTABLE DISCARDABLE BEGIN    IDS_APP_TITLE           "resource_file"    IDS_HELLO               "Hello World!"    IDC_RESOURCE_FILE       "RESOURCE_FILE"END

So far, we've mostly been tossing unnecessary things out. Not so with the string table, which is a key tool for several reasons. First, Windows CE has aggressively embraced the world market for handheld and palmtop computers. This is the motivation behind CE's standardization on Unicode. Putting all the application's static text in the string table means that an application can be fully translated by manipulating only the resource file and the help files. It doesn't even have to be recompiled, only linked with a new language version of the resource file. More important, however, is the string table's potential to conserve the runtime memory. In a nutshell, here's the memory advantage of using the stringtable.

Every Windows CE application occupies a region of read only memory in which the program image and read only static data are stored. This region is separate and distinct from the read/write memory used by an executing application. String resources are stored in read only memory, never used en masse, but instead loaded on demand at runtime by an application. This dramatically reduces the application's footprint in the memory region used for the application heap and stack.

Page 3 of 4

This article was originally published on October 17, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date