February 28, 2021
Hot Topics:

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

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

Locate the literal text in your application and move it to the string table. Replace the literals with calls to LoadString.


Here is the menu section for the resource_file application:

// Menu//IDC_RESOURCE_FILE MENU DISCARDABLE BEGIN    POPUP "&File"    BEGIN        MENUITEM "Open",                        ID_FILE_OPEN        MENUITEM "Close",                       ID_FILE_CLOSE        MENUITEM "Save",                        ID_FILE_SAVE        MENUITEM "SaveAs",                      ID_FILE_SAVEAS        MENUITEM "Print",                       ID_FILE_PRINT        MENUITEM "Print Setup",                 ID_FILE_PRINTSETUP        MENUITEM SEPARATOR        MENUITEM "E&xit",                       IDM_EXIT        MENUITEM SEPARATOR        MENUITEM "Recent Files",                ID_FILE_RECENTFILES    END    POPUP "More Menus"    BEGIN        POPUP "Submenu 1"        BEGIN            MENUITEM "Item1",                   ID_SUBMENU1_ITEM1            MENUITEM "Item2",                   ID_SUBMENU1_ITEM2        END    END    POPUP "&Help"    BEGIN        MENUITEM "&About ...",                  IDM_ABOUT    ENDEND

With menus, we come to a serious porting effort. First, we'll look at what we can get rid of and then we'll examine the changed nature of menu handling under Windows CE.

In the File menu, you can eliminate Exit because it duplicates a standard element on the Windows CE menu bar. You can also eliminate File.Print Setup. Printing is supported on CE devices only thru the serial or infrared ports, which essentially amounts to transferring a file to a desktop computer and delegating to its printer, so you can't effect changes in printer setup from the handheld. For this reason you may want to eliminate File.Print, since it's basically a subterfuge for moving a file to the desktop and doing the file handling there.

Skipping over the "More Menus" popup for now, look at the "Help" menu. It's only purpose in this case is to display an item that shows the application's about box. "Help" should go because it is a waste of valuable screen real estate. The About box. Should go because it's a waste of valuable memory resources. If you feel strongly about displaying copyright and version info, use MessageBox when the program opens to do this. The dialog template and code that implants the MessageBox function is already present, so using it to display a splash screen with copyright, owner and version number information incurs very little overhead.

Now let's look more closely at the "More Menus" item. This is our first trela instance of making a choice to keep or eliminate a feature based on its congruence with the spirit of the Windows CE environment. "More Menus" resource description is shown below:

    POPUP "More Menus"    BEGIN        POPUP "Submenu 1"        BEGIN            MENUITEM "Item1",                       ID_SUBMENU1_ITEM1            MENUITEM "Item2",                       ID_SUBMENU1_ITEM2        END    END

Floating menus and popup submenus are a key thing for which to be on the lookout when deciding whether to move existing menu code or to undertake redesign. If you have nested POPUP statements in the menu portion of the resource file, you need to consider changing the menu design. More that one level of nesting ( e.g. a POPUP submenu that include another POPUP) mandates. POPUPS on the desktop are used to help organize groups of relationships among menu items. On a CE device, scarcity of memory and screen real estate make this approach cumbersome and wasteful.

Windows CE Menu Bars

From a realistic point of view, users aren't likely to be doing (or attempting to do) a very large variety of things at one time on a CE device. Because of their small screen size and relatively slow processing speed, it's reasonable to assume task-oriented patterns of user behavior. Probably for this reason, as well as the physical limits of the device, the designers of Windows CE have emphasized a more flexible, dynamic method of displaying menus than the one on which we mostly relied on the desktop. CE's use of menu bars provides a highly efficient way of displaying compact menus that are tailored to the task in which the user is engaged.

Instead of creating one menu for an application that presents every possible action or mode, you dynamically create and display a variety of task specific menu bars. When the user signals a change in task activity, you destroy the old menu bar and create a new one that supports the require task.

Next, lets take a look at an application that demonstrates the versatility of menu bars. Before we do so, I'll say a word about the source files of the example apps. I use Visual C++ to build and test my Windows CE applications, both for the purposes of this book and in my business. I have found that in order to get things to build and link smoothly (most particularly, in order to avoid problems with unresolved function references at link time ), I start new projects using the following procedure:

Figure 2 - Create a Windows CE Project

Open the dialog box shown above from the File.New.Project Menu. Choose WCE Application from the left pane, and check every processor you wish to target in the Platforms pane. This last bit is important, because it's difficult to add platforms later.

Figure 3 - Choosing Initial Project Files

Choose "A typical "Hello World" application from the list in this dialog box. Though it's tempting to start with an empty project and import some of your own files into a clean space, it hasn't worked well for me. Using the "Hello World" files sets up all the linkage parameters and is much faster and less error prone.

Figure 4 - Files and target platforms for the new project

Build and run the Hello World app before you go on. In particular, check it's list of target platforms to make sure you got all of the ones you intended. There is a pair of toolbar dropdowns that you can check if you use Visual C++. The first is The WCE Configuration bar, which shows the available Windows CE configurations. It should include entries for the Handheld PC and the Palmtop PC, plus the version numbers of the SDK for each. Another control, the Build Toolbar, list all of the targets for which you can generate code in this project. The list should include all the processor types you specified in the Platforms pane of the New Project window, with Release and Debug build versions for each.

Looking Ahead

In the next installment, we'll fully explore the Windows CE menu bar. You'll learn how to build menu bars and insert controls. Since you'll probably be leaving at least some of your desktop application's menu functionality behind, we'll introduce alternative interface techniques which are both in the spirit of CE and in keeping with the limited screen size of typical CE devices. In particular, we'll focus on how to build, display and manage command bars, a key Windows CE interface construct.

About the Author

Nancy Nicolaisen is a software engineer who has designed and implemented highly modular Windows CE products that include features such as full remote diagnostics, CE-side data compression, dynamically constructed user interface, automatic screen size detection, entry time data validation.

In addition to writing for Developer.com, she has written several books including Making Win 32 Applications Mobile. She has also written numerous articles on programming technology for national publications including Dr. Dobbs, BYTE Magazine, Microsoft Systems Journal, PC Magazine; Computer Shopper, Windows Sources and Databased Advisor.

Page 4 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