Development | .NET Compact Framework

SmartPhone 2003 and .NETcf Primer
Written by casey chesnut  [author's bio]  [read 45855 times]
Edited by Derek

         

Page 1  Page 2  Page 3 

Projects

When creating a VS .NET SmartPhone project, we get the standard Smart Devices Application Wizard for choosing a platform (Windows CE, Pocket PC, and SmartPhone) and then the project type. The project types differ in that Windows CE can create Console apps, while Pocket PCs call it Non-gui applications, and SmartPhones entirely lack a similar type; allowing you to only choose between a Windows app, Class lib, and an Empty project. The projects do get the familiar .csdproj extension. When coding, you've got the same .NETcf class libs (plus SP1) that you have for CE and PPC. The only parts that are missing are some UI controls and the SqlCe bits. In VS .NET the UI device controls are not available for selection, although they do show up in intellisense. If you try to instantiate them (e.g. Button b = new Button();) then you will get a runtime error of NotSupportedException. Since the managed bits are almost the same between all devices, i attempted to port a number of PPC apps to SP. Basically creating the new project type and including the files was all that was required to get it to build. Then it was a matter of fixing runtime bugs from non supported UI elements and a lack of SqlCe (e.g. the same old write once - test everywhere scenario with diff java runtimes). The recent GoalieGame ported with only a minor menu change!

of course i let the computer win this time

So if you targeting your app for both the PocketPC and SmartPhone you should be able to keep a pretty common codebase. At runtime, you might be able to tell what type of device is available with the following results (else pInvoke GetVersionEx). NOTE these results are from the different emulators.

PlatformID pid = Environment.OSVersion.Platform;
Version v = Environment.OSVersion.Version;
//PID Major.Minor.Build.Revision
//WinCE 4.20.1088.-1 //sp 2003
//WinCE 4.20.1081.-1 //ppcPe 2003
//WinCE 4.20.1081.-1 //ppc 2003
//WinCE 3.0.11171.-1 //ppc 2002

An interesting side item is that I tried to port the PPC SliderPuzzle sample, and it built instantly, but the SP 2003 emulator was not able to open the sample jpg that it included. Also had problems with some other jpgs, but have not followed up on it, although i saw there was a similar newsgroup thread.

Windows.Forms

My first SP app developed from scratch was appropriately Hello World. Was going to have a button that popped up a MessageBox ... except I was quickly reminded that SPs do not have touch screens when the Button control in the Toolbox was grayed out. Doh! Instead of Buttons, you can use a Menu. The menu is limited in that you can only have 2 top-level MenuItems, and the 1st top-level MenuItem cannot have any children. The 2 top-level MenuItem restriction is because they map to hardware buttons on the phone. The 1st MenuItem restriction is based on logo requirements, and I dont think it should be enforced by the runtime at all (let me make a non-standard GUI if i want to!). Either way, the VS .NET designer does not enforce these and you will get runtime errors if you dont follow them. Did i mention runtime errors? Other niceties of the menu is that it will map the 1st 10 (1-9, and then 0) MenuItems to the number keypad of the phone for usability sake. It can display 11 items at a time; if you go over 11 items, it will only show 9 with scroll up and scroll down markers to see the rest. The following pic shows a menu selection of 2 -> 2.1 -> 2.1.1 -> 2.1.1.1. You can see the scroll bars as well.

Without a touch screen, we also lose the SIP keyboard. To do text entry, you have to use the number pad of the phone. It's default input mode is Multi-tap (e.g. tapping #2 3 times enters 'c'), but its Input Mode can be changed to T9 (e.g. tapping #'s 43556 once each would go against a dictionary and enter 'hello'), Numbers, and Text. Tested some code on the emulator and got it to successfully switch to / from Numbers mode. Calls to switch it to T9 returned successful but it does not seem to be supported by the emulator.

The documentation gives you the list of controls that you do have, but the following table seems more useful by quickly reminding you what you dont have (e.g. we lost 13, maybe 14, controls that we had for the PPC).

.NETcf (SP)	.NETcf (PPC)	.NETfx
CheckBox ComboBox HScrollBar ImageList Label ListView MainMenu Panel PictureBox Pointer ProgressBar TextBox Timer TreeView VSrollBar DataGrid (psych)	Button ContextMenu DomainUpDown InputPanel ListBox NumericUpDown OpenFileDialog RadioButton SaveFileDialog StatusBar TabControl ToolBar TrackBar	CheckedListBox ColorDialog CrystalReportViewer DateTimePicker ErrorProvider FolderBrowserDialog FontDialog HelpProvider LinkLabel MonthCalendar NotifyIcon PageSetupDialog PrintDialog PrintDocument PrintPreviewControl PrintPreviewDialog RichTextBox Splitter ToolTip

DataGrid shows up in the Device Controls Toolbox, but i dont think it should (it causes a compile-time error for me)? Other differences are that ListViews and TreeViews are supposed to take up an entire Form based on logo requirements. In this case the VS.NET designer defaults to the logo requirement, but you can resize the controls to be different, and it is not enforced by the runtime. The problem then is that once a Panel, ListView, or TreeView has focus; it will not give it up ... so we have to write code to get around that if necessary.

The MessageBox is also worth noting because it is full screen and only supports 2 buttons. If you specify a MessageBox with more then 2 buttons (e.g. MessageBoxButtons.YesNoCancel) then you will get an ArgumentException. From the pics below, you should realize that you should never use the default dialog settings (same as Ok-None below) because they are too plain. The TitleBar 'caption' shows the MessageBoxIcon that was chosen, and the 'text' shows the MessageBoxButtons. Notice how the softkey text changes too.

Debug.Write still doesnt show up, and below is what Trace.Assert messages look like:

We still have the Screen object to tell us the bounds and working area. Bounds is reported as 176x220, while WorkingArea returns 172x180 (due to the Title and Menu bar taking up 20 pixels each). If you delete the Menu, WorkingArea still returns 172x180, instead of reclaiming the 20 pixels from the missing Menu. You can also make full screen forms (this.WindowState = FormWindowState.Maximized;) and the WorkingArea still returns 172x180 instead of reclaiming 20 pixels for the missing Title (i consider both of these bugs). Forms can be made to scroll as well. It is a little different than how you could do it in the PPC, because of tab order and control focus differences, due to not having a touch screen. This can be overcome by hooking KeyDown events of the navigation pad, or by hooking OnFocus as different controls receive Focus.

Hooking the hardware buttons is also important on devices. From sample code in the SDK, I was able to hook both soft keys (KeyDown) and the back key (KeyPress). I was not able to hook volume up / down or the record buttons with purely managed code, but I bet it is possible with a MessageWindow for receiving unmanaged Messages.

Previous Page  Next Page 

Back to .NET Compact Framework | [Article Index]