Porting a registry viewer application from Pocket PC to SmartPhone 2002

• Download demo project - 18 Kb

Introduction

There are a lot of Windows CE 3.0 applications that can prove useful for Smartphone 2002 platform. This platform is based on Windows CE 3.0 that is a good sign for software porting. However, this new mobile platform has a lot of specific points. A small content area, the lack of a touch screen, and other user interface concepts are potential problems for a software developer. The key differences between the platforms are outlined in Introduction to Smartphone 2002 for Pocket PC developers article.

To experience porting aspects of the new platform I have decided to port an existing Pocket PC application that does not use MFC. There is a simple registry viewer sample that comes with Pocket PC 2002 SDK called "PSPCMonkey". This article describes the porting process of this application from the user interface design to the implementation details.

This article also demonstrates some techniques specific to Smartphone 2002 platform:

• Working with the new menu bar resource including a workaround for the known problems related to it.
• Creating expandable edit and list boxes.
• Implementing "Back" key support.
• Creating labels with the standard Smartphone 2002 appearance.

Beginning

The very first idea is to compile the application without any changes for Smartphone 2002 platform. It is written in pure API therefore we have good chances to get good results from the compiler...

We got a perfect result of 0 error(s), 0 warning(s) as it was expected. Let's run the application and have a look on the Smartphone 2002 side.

The result does not look too good. A quick review of the application gives the following items to do:

• List boxes: According to Smartphone 2002 guidelines list boxes should contain only one row.
• Menu bar: The application should contain its own menu bar.
• Back key: The application should support "Back" key.
• Buttons: Buttons are not supported under Smartphone 2002.
• Content area: Controls do not fit to the content area. A dialog can use vertical scrolling to place all controls.
• Labels: Labels should look like standard Smartphone 2002 labels.
• Title bar: The title bar should show the application name. Titles of message boxes should not be too long.
• Controls behavior: There is no a touch screen.

User Interface Design

The user interface design is the most important aspect of the porting. The small content area, a touch screen missing, and another set of controls should be considered. The user interface design will be divided into several steps.

Layout Design

The main rule of placing controls on Smartphone 2002 screen is "one control should take one row". It is recommended using labels to indicate what type of information is displayed in the control. Labels should be placed directly above the control.

Controls

According to Smartphone 2002 guidelines list boxes should contain only one row. Navigation can be done in 2 ways: using a spin control with Left/Right buttons and using expanded view of the list. Expanded view of the list is quite useful in our case since there can be a lot of items in the list.

Buttons are not supported under Smartphone 2002 platform. A good solution is to replace them by items in the menu bar.

The action button of the menu bar (left soft key) will replace a mouse click. The user will use this key to step into the registry key. The second soft key is usually used for the menu, but we don't have a menu in our simple application. Therefore we will have only one more key in the menu bar, the "Back" item that will replace the "Back/Up" button from the original application.

Behavior

Often the user interface of an application relies on mouse (stylus) events. Smartphone 2002 does not have a chance to produce a click since it does not have a touch screen. In our case we have very simple application, but it cannot work without a touch screen! The problem is that list boxes use click events for the navigation. We will replace those clicks with the special menu item in the menu bar.

Implementation

Expandable List and Edit boxes

We need to reduce the height of the list boxes and add spin control for items selection and for expanding. The following resource code creates one list box with desired functionality.

  LISTBOX      IDL_LISTBOX,4,15,131,10, WS_TABSTOP | WS_VISIBLE | 
               LBS_NOINTEGRALHEIGHT
  CONTROL      "", IDC_UPDOWN, UPDOWN_CLASS, WS_VISIBLE | 
               UDS_AUTOBUDDY | UDS_HORZ | UDS_ALIGNRIGHT | 
               UDS_ARROWKEYS | UDS_SETBUDDYINT | UDS_WRAP | 
               UDS_EXPANDABLE, 0,0,0,0

The following resource code creates an expandable edit box. Since it is a viewer application the read-only flag is applied.

  EDITTEXT     IDE_TEXTOUT,4,70,131,12,ES_MULTILINE | 
               ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_READONLY | 
               WS_TABSTOP
  CONTROL      "", IDC_UPDOWN, UPDOWN_CLASS, UDS_AUTOBUDDY | 
               UDS_ALIGNRIGHT | UDS_EXPANDABLE | UDS_NOSCROLL, 
               0, 0, 0, 0

Menu Bar

The menu bar resource is a new resource and the resource editor does not handle it correctly. There are 2 known problems connected with menu bar resources: undefined I_IMAGENONE keyword and converting a menu bar resource to binary format by the resource editor. You can find more details about the problem and the workaround in this article.

To solve those problems I put the menu bar resource in a separate custom resource file. To do it I created a separate text file and added the following menu bar code to it.

  IDR_MENUBAR RCDATA
  BEGIN
   IDR_MAINMENU, 
   2,            
   I_IMAGENONE, IDM_ENTER, TBSTATE_ENABLED, TBSTYLE_BUTTON | 
       TBSTYLE_AUTOSIZE, IDS_ENTER, 0, NOMENU,
   I_IMAGENONE, IDM_BACK, TBSTATE_ENABLED, TBSTYLE_BUTTON | 
       TBSTYLE_AUTOSIZE, IDS_BACK, 0, NOMENU,            
  END

Then I saved the file as PSPCMonkey.rc2 and added it to the project. The last step was to include this file to compile time resource includes using View->Resource Includes menu item.

This approach solves the problems with this custom resource. Now the menu bar resource cannot be edited in the resource editor; it should be edited as a text file.

Also we need to add strings that are used in the menu bar to our string table.

  STRINGTABLE DISCARDABLE 
  BEGIN
    IDS_BACK                "Back"
    IDS_ENTER               "Enter"
  END

Back Key

The Back key should return the user to the previous screen. In edit controls it also functions as Backspace. All edit boxes in our application are read-only therefore the Back key presssing in the main window should hide our application. It is recommended to return the user to a "fresh" state each time an application is executed. Therefore the Back key will close our dialog.

To implement this behavior we should not override the Back key in our dialog. In this case the Back key sends WM_COMMAND/IDANCEL to the dialog box. We need only to add the standard handle to the main switch of the DialogProc.

  // ...
  case WM_COMMAND:
    switch (LOWORD(wParam))
    {
      // User chose to close the dialog
      case IDCANCEL:  //Handles the BACK KEY
        EndDialog(hDlg, TRUE);
        break;
      // ...

Title Bar

Due to the limited size of the task bar an application title should be short and concise. Also the title can be changed for the child windows. For example, a message box will show its title in the title bar. In our application the title bar will show "Registry Editor" for the main window and "Error" for message boxes with error messages.

Labels

The standard Smartphone 2002 applications (for example, Inbox) use 11-point bold Nina for the labels, but not the current dialog font. The following code creates this font.

  HFONT CreateLabelFont()
  {
    LOGFONT lf;
    memset(&lf, 0, sizeof(LOGFONT));
    HDC hdc = ::GetDC(NULL);
    lf.lfHeight = -11 * GetDeviceCaps(hdc, LOGPIXELSY) / 72;
    ::ReleaseDC(NULL, hdc);
    lf.lfWeight = FW_SEMIBOLD;
    return CreateFontIndirect(&lf);
  }
		

Now we can assign the created font to the labels in WM_INITDIALOG handler.

  g_hLabelFont = CreateLabelFont();
::SendDlgItemMessage(hDlg, IDC_STATIC1, WM_SETFONT, 
    (int) g_hLabelFont, 0);
::SendDlgItemMessage(hDlg, IDC_STATIC2, WM_SETFONT, 
    (int) g_hLabelFont, 0);
::SendDlgItemMessage(hDlg, IDC_STATIC3, WM_SETFONT, 
    (int) g_hLabelFont, 0);
::SendDlgItemMessage(hDlg, IDC_STATIC4, WM_SETFONT, 
    (int) g_hLabelFont, 0);
		

And destroy the font when it is no longer needed (in WM_DESTROY handler).

  case WM_DESTROY:
    DeleteObject(g_hLabelFont);
    break;
		

Conclusion

From the compiler point of view it is easy to port a Windows CE application that does not use MFC to Smartphone 2002 platform. However, porting will not be so easy. Efforts will be spent on the user interface design. You should design your windows for the small content area; consider new controls, new behavior that does not consume mouse clicks, the Back button, and a title bar.

It seems that the most application should save their usability. We have lost a touch screen, quite a big content area, and some controls, but we have got expandable list and edit boxes, spinners, scrollable dialogs, and a lot of hardware keys. I think that those new aspects should compensate the lost ones for applications that can be considered as useful on the Smartphone 2002 platform as they are on the Pocket PC platform.