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