Author:
Yaroslav Goncharov (If you need to reprint, please contact the original author)
May 22, 2002
Original link:
Http://www.codeguru.com/cpp/w-p/ce/smartphone/Article.php/c3531/
Introduction
There are many applications for Windows CE 3.0 to prove the importance of this operating system for the Smartphone 2002 platform. This platform is based on Windows CE 3.0; this can be a good sign for software transplant. However, this new mobile platform still has a lot of special places, such as a smaller screen, does not support touchscreen and some other user interface concepts, which may become potential problems of software developers. About the main difference between these platforms,
Introduction to Smartphone 2002 for Pocket PC Developers is already listed.
In order to feel the various aspects to the new platform, I decided to transplant an existing Pocket PC application, it did not use the MFC. There is a simple registry view tool routine in the Pocket PC 2002 SDK. This article describes the transplantation process of this program, including various parts of the user interface to detailed implementation.
This article also demonstrates technologies on the SmartPhone 2002 platform, for example:
· Using new menu strips, including it a known related issue and its solution.
• Create an extensible edit box and list box.
· Realize the support of the Rollback button.
· Create a standard SMARTPHONE 2002 label.
Pocket PC
Smartphone 2002
Start
The initial first step is to compile applications without any changes in the Smartphone 2002 platform. It is written in pure API, so we have the opportunity to get a good result from the compiler.
We got a perfect result --0 Error (s) and 0 Warning (s), just as before we expect. Let us now run this app, take a look at it from the perspective of Smartphone 2002.
This result doesn't look too good. Quickly review this program, we will find that there is still the following things to do:
• List box. The list box should only include one line according to the guidelines of the Smartphone 2002.
· Vegetables. This application should include a menu bar itself.
· Returning. Applications should support a "rollback" key.
Button. SMARTPHONE 2002 is not supported by the button.
· Screen area. The control is not suitable for the screen. The dialog can use vertical scrolling to locate all controls.
·label. The label should look like the standard Smartphone 2002 tag.
· Title bar. The title strip should display the name of the application, and the title of the message box should not be too long.
· The behavior of the control. Smartphone is no touch screen.
User interface design
The design of the user interface is the most important aspect of transplantation. Smaller screens, there is no touch screen and this other set of controls should be considered. User interface design should be divided into steps.
Layout design
The most important rule on the SMARTPHONE 2002 screen is "a control should take a line". It is recommended that you use tags to indicate what type of information displayed in the control. The label should be placed directly above the control.
Control
The list box should only include one line according to the guidelines of the Smartphone 2002. Browse can be implemented in two ways: using a fine-tuning control with the left / right button and the expansion view of the list of lists. The list of expansions of the list is very useful in this case, because there are many items in the list.
Under the Smartphone 2002 platform, it is not supported, a good solution is to replace them to menu items on the menu bar.
The action button of the menu bar (soft key on the left) will instead of the mouse. Users will use this button to enter the key of the registry. The second softkey is usually used for menus, but we have no menus in this simple application now. Therefore, we also need another key in the menu bar: "Retreat" item replaces the "Retreat / Up" button for the original application. behavior
Typically, the user interface of the application is dependent on the mouse (handwriting) event. Smartphone 2002 does not have an opportunity to create a click event because it has no touch screen. In this case, we have a very simple application, but it is unable to work without touch screen! The problem is that the list box is to use click to browse. We will use the special menu items in the menu bar to replace these click.
achieve
Scalable list box and edit box
We need to reduce the height of the list box and add micro-regulators to implement item selection and expansion. The following resource code created a list box resource based on these needs.
LISTBOX IDL_LISTBOX, 4,15,131,10, WS_TABSTOP | WS_VISIBLE | LBS_NOINTEGRALHEIGHTCONTROL "", IDC_UPDOWN, UPDOWN_CLASS, WS_VISIBLE | UDS_AUTOBUDDY | UDS_HORZ | UDS_ALIGNRIGHT | UDS_ARROWKEYS | UDS_SETBUDDYINT | UDS_WRAP | UDS_EXPANDABLE, 0,0,0,0 following code creates resources An scalable edit box because this is a viewing tool application, so using a read-only tag.
EDITTEXT IDE_TEXTOUT, 4,70,131,12, ES_MULTILINE | ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_READONLY | WS_TABSTOPCONTROL "", IDC_UPDOWN, UPDOWN_CLASS, UDS_AUTOBUDDY | UDS_ALIGNRIGHT | UDS_EXPANDABLE | UDS_NOSCROLL, 0, 0, 0, 0
Menu
Menu bar resources are a new resource and the resource editor cannot process it correctly. About menu bar resources, two issues known are: an undefined i_imagenone keyword, and the resource editor converts the menu bar resources to a binary format.
In order to solve these problems, I put the menu bar resources in a separate custom resource file. To do this, I created a separate text file and added the following menu bar code.
IDR_MENUBAR RCDATABEGIN 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 I then save the file as PSPCMonkey.rc2, and Add it to the project. The final step is to use the View-> Resource INCLUDES menu item, which contains this file in Compile Time Resource Includes.
This method solves this problem using custom resources. Now the menu bar resource cannot be edited in the resource editor, it should be edited as a text file.
Similarly, we need to add a string for the menu bar display in the string table, just like this. StringTable DiscardableBegin IDS_BACK "Back" IDS_ENTER "ENTER" end
Back button
The rollback key should be used to return to the previous screen. In the edit control, it is also used as a backup button. All edit boxes in our app are read-only, so, pressing the back button in the main window to hide our app. I recommend that every time the application is executed, it will return the user to a "update" state. So, the rollback button should close our dialog.
To achieve this, we should not rewrite the return button in our dialog. In this case, the rollback key should send a WM_COMMAND / IDCANCEL message to the dialog. We only need to add standard processors to DialogProc's primary Switch.
... CASE WM_COMMAND: SWITCH (WPARAM) {// User Choose Close Dialog Case IDCancel: // Handling Back Key EndDialog (HDLG, TRUE); Break; ...
Headline
Due to the limited size of the taskbar, the title of the application should be as simple as possible. Moreover, the title can be replaced according to the sub-window. For example, a message box will display its title on the title bar. In our application, the title strip displays "Registry Editor" in the case of the main window, and "error" is displayed in the case where the error message message box.
label
Standard Smartphone 2002 applications (for example, inbox) use 11 Nina 11, not the font of the current dialog. The following code created this font.
HFONT CREATELABELFONT () {Logfont LF; Memset (Logfont)); HDC HDC = :: getDC (null); lf.lfheight = -11 * getDeDeviceCaps (HDC, Logpixelsy) / 72; :: releasedc ( NULL, HDC); lf.lfweight = fw_semibold; Return CreateFontIndirect (& lf);} Now we can assign this created font to each label in the WM_INITDIALOG message processor.
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, when this font is not required (in the WM_DESTROY processor) destroy it.
Case WM_DESTROY: DELETEOBJECT (G_HLABELFONT); BREAK;
to sum up
From the compiler's point of view, it is very simple to transplant a Windows CE application that does not use MFC to the Smartphone 2002 platform. However, transplant is not as simple as it is. Your most important efforts will cost it on the design of the user interface. You should design your window for this small screen; consider these new controls, new behaviors, rollback keys, and title bar that cannot use the mouse click. It seems that most applications should guarantee their usability. We have lost touch screens, big screens, and some controls, but we get the scalable list box and edit box, fine-tuning control, scrollable dialogs, and a lot of hardware buttons. I think these new aspects should be able to compensate for these lost things, play a role in the application of the Smartphone 2002 platform.
download
Download sample project
