Porting from the Pocket PC to Smartphone 2002

This article shows you how to port a registry viewer application from the Pocket PC to Smartphone 2002.

.

Environment: Windows CE

Introduction

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

To get a feel for 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 the 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 the Smartphone 2002 platform, such as:

• 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.

A Pocket PC.

A Smartphone 2002.

Beginning

The very first step is to compile the application without any changes for the 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) and 0 warning(s), as was expected. Let’s run the application and look at the Smartphone 2002 side.

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

• List boxes. According to the 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 a “Back” key.


• Buttons. Buttons are not supported under Smartphone 2002.


• Content area. Controls do not fit in 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 touch screen.

User Interface Design

The user interface design is the most important aspect of the porting. The small content area, a missing touch screen, 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 the Smartphone 2002 screen is “one control should take one row.” It is recommended that you use labels to indicate what type of information is displayed in the control. Labels should be placed directly above the control.

Controls

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

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

The action button of the menu bar (left soft key) will replace a mouse click. Users 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 a user interface of applications relies on mouse (stylus) events. Smartphone 2002 does not have a chance to produce a click because it does not have a touch screen. In our case, we have a very simple application, but it cannot work without a touch screen! The problem is that list boxes use click events for 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 controls for items’ selection and for expanding. The following resource code creates one list box with the 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. Because 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 two known problems connected with menu bar resources: an undefined I_IMAGENONE keyword and converting a menu bar resource to binary format by the resource editor.

To solve those problems, I put the menu bar resource into the 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 IN the compile time resource includes, using the 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, as shown below.

  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 a Backspace key. All edit boxes in our application are read-only; therefore, presssing the Back key in the main window should hide our application. It is recommended that you return the user to a “fresh” state each time an application is executed. The Back key then 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, and not the current dialog font. The following code creates this font.

HFONT CreateLabelFont()

{

  LOGFONT lf;

  memset(&LT, 0, sizeof(LOGFONT));

  HDC hdc = ::GetDC(NULL);

  lf.lfHeight = -11 * GetDeviceCaps(hdc, LOGPIXELSY) / 72;

  ::ReleaseDC(NULL, hdc);

  lf.lfWeight = FW_SEMIBOLD;

  return CreateFontIndirect(&LT);

}

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 the Smartphone 2002 platform. However, porting will not be so easy. Your main 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 most applications should save their usability. We have lost a touch screen, a lot of content area, and some controls, but we have gotten 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 useful on the Smartphone 2002 platform.

Download

Download demo project — (18 KB)