Page 1
Page 2
Page 3
This installment took longer than I
would have liked. I spent the month of July preparing for
GenCon, one of the largest gaming conventions in the world.
This event brings together players of card games (Magic:
the Gathering
- not the poker kind) and Role Playing Games (the Dungeons
and Dragons kind not the computer kind) for four days
of constant fun. I run several adventures (see www.webcommando.com/gencon)
and took my trusty Pocket PC with me. This was a great opportunity
to showcase the power of the Pocket PC and some of the applications
I wrote (www.rpgcommando.com).
The tools I brought along were Illium
Software's ListPro to track nuggets of gaming information,
my own Slicer and Dicer for advanced dice rolling, and my
Character Sheet program to track ability scores of the antagonists
of the adventures. I combined these with Pocket Word for
descriptions and notes. I also added a J2ME application
I wrote running on my iDEN phone for simple dice rolling;
each button on the keypad was represented a different style
of dice (I am by nature an equal opportunity small device
developer!). With all this wonderful technology, I was hoping
I could eliminate binders full of maps and notes. I was
also thought I would never need to pull out my big bag of
dice! Figure 1, below shows my techno-tools setup.
My solution worked pretty well, I was
much more efficient and could spend more time working closely
with players. I constantly wandered around the table, staying
close to the action. However, I still found myself returning
to my notebook. It was much quicker to page through my notes.
Also, switching between applications was tedious and I needed
to give too much attention to navigating the interface.
This limitation might be due to fact that Pocket Word doesn't
have a table of contents feature. As a developer, it made
me wonder if there wasn't a better way to manage all this
information. Perhaps I'll write something new to try next
year!
Ok, enough on gaming, lets talk Windows
CE Logo Certification…
As promised last time, we'll look at
some more at becoming Windows CE Logo compliant. John Lescoulie
from Veritest was kind enough to provide a list of the top-ten
problems they find when applications are tested. I think
it's useful to mention that Veritest wants to work with
developers and I encourage you to consult them prior to
submitting your application. They want to see you succeed
on the first try!
We'll first take a look at the list.
I've recreated them exactly as Jon sent them and will add
my own comments later.
1) Help system for the application not
integrated with the system TOC
2) The "no user-exposed method for closing the application"
logo requirement is violated
3) Application does not resize when the 80 pixels tall SIP
is up.
4) Application fails to register both 16x16 and 32x32 pixel
icons for main executables and saved files.
5) Application fails to uninstall properly using the CEAppManager
in ActiveSync.
6) Application leaves items behind in the Registry after
uninstall.
7) Application fails to install on one of more processor
types suck as SA1100, SH3, or MIPS.
8) Application fails to function properly on one or more
processor types.
9) Application has a Help button visible to the user in
the UI/Shell instead of enabling Help access through the
Start menu.
10) The "Applications may not use NavBar for anything
application specific" logo requirement is not met with
developers adding icons or text.
I was pleasantly surprised by this list.
I had expect much more difficult problems to tackle. Obviously,
we don't solve all the problems eloquently with our eVB
applications. For example, the icons installed are generic
eVB icons not our own. We can use the code provided by Microsoft
to create an eVC++ loader, but I won't get into this now.
Looking closer at the list…
I was surprised that the number one
issue isn't a problem with complex coding for the numerous
processors, but help for users. Help is often the last thing
on the mind of many developers, but fortunately integrating
help with the Table-of-Contents (TOC) on the Pocket PC isn't
difficult. The number nine issue is also related to help.
Placing a help button or menu item within the application
is not allowed under Microsoft's guidelines, though many
of us are guilty of taking this short cut. I've decided
to spend time building help into an application that handles
these issues. Before we get to that, we should look at a
couple of interesting entries on the list.
Last time we looked at our second big
hitter on the list. To remove the "OK" and ability
to exit, I created an application that used the list view/card
model for an application. Refer to part one (ß link
to part one) of this series to learn more.
Working with the SIP can be a bit tricky,
leading to the number three problem. It requires resizing
your content and avoiding placing input controls under the
keyboard when it pops up. My article on scrollable forms
(ß link) shows one way to handle changes in the SIP.
I created a form with a scroll bar on the side that allows
the user to move the form up and down as desired.
Finally, to avoid failing because you
used the NavBar on top of the screen…well don't. That
solves that issue pretty easily. If you want to add buttons,
use the menu bar at the bottom of the screen.
Next Page