The screen for the Smartphone is typically smaller than that of the Pocket PC. It is for display only and does not trigger clicked events in response to user actions such as tapping an item with a stylus. It primarily serves as a telephone, not as a Personal Digital Assistant (PDA). A user interacts with a Smartphone through its keypad. Keypad entry is typically a one-handed operation.
Smartphones support several text entry modes from the Smartphone keypad. The current text entry mode is indicated in the title bar of a window when focus is in an editable field. For numeric data entry, the title bar has an icon displaying “123.” For alphanumeric or multitap mode, the icon displays “abc”, or “ABC” for entry of capital letters. Users can switch among modes by pressing or holding the asterisk key on the Smartphone keypad. (In numeric mode, just pressing the asterisk key enters an asterisk in the edit field.)
In PocketBuilder applications, you can assign a text entry mode to an edit field by setting its IMEMode property.
Typically applications must be signed with trusted certificates available on the Smartphone device. If you distribute an application in a CAB file, the CAB file must also be signed. PocketBuilder lets you select certificates for signing applications and CAB files in the Project painter. Although PocketBuilder supplies certificates for testing, you must purchase or generate your own certificates.
In the window layout for a Smartphone application, you should use one control (and control label) only per line.
In PocketBuilder applications, list boxes and drop-down lists are automatically converted to spinner controls. A spinner control is like a typical spin control on the desktop, except that arrows point to the right and left rather than up and down.
A user can spin through the items in a list by selecting the right or left arrow on the Smartphone’s 4-way navigation pad. Otherwise, the user can press the Action button when a spinner control has focus. This opens a dialog box with the complete list of items. The user can select an item in this dialog box with the up and down arrows. After selecting an item, pressing the Action button again validates the selection and returns the user to the window with the spinner control.
Figure D-1 shows a window with a ListBox and a DropDownListBox control that have been converted to spinner controls. Spinner controls provide no indication of their original design-time control type. The only differences in the controls seen in the figure are due to their data content, background color property, and the current focus indicator. The focus indicator is a rectangular box drawn around the control.
Figure D-1: Window with two spinner controls
Smartphones have two soft menu keys that link to the two main menus required for Smartphone applications. The left menu key typically opens a menu for quick, commonly used actions. In many Smartphone applications, when it functions to create new items or documents, this menu is labeled New. It is labeled Done or OK to save parameter settings and return to a previous screen. A Cancel menu item or button should be available for any windows that an application user can edit.
The right menu key typically opens a menu that has submenu items. If a right menu is not needed, it can be left blank, and the menu item can be left unscripted, but it still must be included in any menu object that you deploy with your application. Do not use ellipsis marks (...) in a menu label.
Indication of current focus is often problematic in Smartphone applications, particularly for noneditable controls.
If you add more than one command button to an application, it is best to select the Default property for one of the buttons. The Default property adds thicker black lines around the button, which serve, initially, as a focus indicator. Unfortunately, unless you set the Default property for the first button to false (for example, in a LoseFocus event script), the thick black lines remain. However, the other buttons on the same window now display the thick black lines when they have focus and display thinner black lines when they do not have focus.
When an editable control gains focus, it is typically surrounded, like the Default command button, by thick black lines in the form of a rectangle. The rectangle also typically encloses the control label.
The Smartphone platform is not particularly well suited for tabbing among edit fields or scrolling in a window. The arrows on the 4-way navigation pad can be used to change the current focus, but with some controls (such as list views, multiline edit boxes, and DataWindows), the change in focus remains internal to the control or to a column in the control.
To change focus to a particular control, you can use the PowerScript SetFocus function in a ChangeFocus menu item. To provide a user with the ability to tab among columns in a DataWindow, it is useful to create a Tab menu item that mimics a Tab key press action. The following menu item script sends a Windows WM_KEYDOWN message for a Tab key press to a DataWindow control, enabling the user to tab among editable columns in the DataWindow object:
send(Handle(w_myMainWindow.dw_1),256,9,0)
When you use the above methods, you cannot change focus to a control that has a tab order of 0 or to a DataWindow column that is read-only. You can, however, scroll the window or DataWindow to display the control or read-only column. The following code in a ScrollToFirstColumn menu item script causes the first column to display on a screen even when the first column is read-only:
string modstring
modstring=”DataWindow.HorizontalScrollPosition=” &
+ String(0)
w_myMainWindow.dw_1.Modify(modstring)
If an application does not save data in the flash memory storage file system or on a storage card, the data is lost when the user turns off the device.
The Microsoft online Help for the Smartphone SDK recommends that you simplify Smartphone memory management by not providing a Close button on an application toolbar or enabling Exit on a File menu. Memory use for running applications is optimized by the Smartphone shell. Smartphone devices send a WM_CLOSE message to close idle applications when demand for memory is high. To preserve an application’s state from one session to another, you can save persistent-state variables to a temporary file after the application receives a WM_CLOSE message, but before the operating system is notified. The next time the application starts, it restores the application state using this temporary file.
