Page 1
Welcome to the world
of Windows CE programming. You are about to step outside of the centrally-heated
comfort of Visual Basic into the brisk fresh outdoors that is eMbedded Visual
Basic (eVB). The object of this article is to help prepare the seasoned VB-er
(and relative newcomer too, as it doesn't necessarily take years of experience
to produce commercial-quality programs) for the transition to the PocketPC development
environment.
Just "cut-down VB" isn't the
right description for it, but you do need to be aware of the limitations that
the smaller memory, screen dimensions and processor speed of the CE platform will
impose on the programs you can write. When you first pick one up it can be a disappointment
to see how crudely the controls are now drawn on the new PocketPC (when compared
with earlier versions of CE), presumably because the performance benefits gained
by not rendering shadows and rounded corners are a worthwhile trade-off.
You are probably already aware that the development environment is much like VB’s
on the surface. Windows NT 4 or 2000 is required, unless you are prepared to do
your debugging on the unit itself. As a VB developer turning to eVB, some of the
luxuries you won't have at your disposal are as follows:
- Arrays
of forms or arrays of controls on your forms are not supported. Convenient arrays
such as Combo1(0), Combo1(1), etc. cannot exist at design time nor can they be
created at runtime.
- Modal dialog boxes, unless you
use the MsgBox() function or follow one of the workarounds documented on several
forums, cannot be used.
- The Debug object is not implemented
in eVB (a serious blow for most VB users). Nor can you hover the mouse pointer
over a variable in the code window and expect to see its current value. Only whilst
the code is stopped at a breakpoint or “watch” can you inspect the value
of a variable.
- All variables are Variants. An even
more serious blow. You can still use the convenience of declaration statements
such as "Dim blnReady As Boolean" and eVB's Intellisense will prompt
you with True and False whilst you're coding, but the blnReady variable can be
coaxed into holding any value you ask it to whilst the program's running - as
is the design with Variants.
- Static variables cannot
be declared within your Subs and Functions, you'll have to declare Private variables
in the code module instead.
- The useful With ... End
With construct from VB is not implemented (the editor handles it but the code
won't run on the client).
- The handy variation of the
Case statement, for example, "Case Is < 32", will not work in eVB.
- You
can't [easily] assign an icon to your compiled application. The .VB program behind
the icon is launched by virtue of association, and this means that you're stuck
with the standard offering unless you write a stub loader EXE in eMbedded Visual
C++ (see
this article).
- The familiar VB editor remains with
us, as it has with VBA (well-crafted core DLLs are to thank for this), and whilst
real-time syntax checking, parameter prompting and formatting of your typing is
still performed by the editor, there is no equivalent to the reassuring "Full
Compile" command. This means that you could distribute code with latent problems
as serious as undeclared variables, and it would only become apparent when the
user hit the offending statement during an unpredicted sequence of events. Which
brings us to the next section - eVB's error handling capabilities.
-
If VB's error handling is crude, eVB's must be prehistoric. Only the statement
"On Error Resume Next" separates trappable errors from the users of
your application. Just like in VB, if you declare an error handler within a function
then all functions (or subs of course) called from within it will fall back to
that handler unless they have their own. The difference is, however, with eVB
you need a greater awareness of how and where your errors might occur in order
to deal with them appropriately. Errors caused by non-declaration of variables,
though, cannot be trapped. Personally I tend to leave out the "unpredictable
error" handling code until near the end of the project.
- A
number of surprises await you as your first application takes shape. Try and use
the Val() function and - though Intellisense guides you through the syntax - this
is not one of the functions implemented in eVB. You must use instead the CLng()
function, but use it with caution because it doesn't tolerate leading spaces in
the string, nor will it return zero when the string leads with a non-numeric character
(it generates an error).
- I recall the despair and
frustration of working with the TabStrip control in early versions of VB on the
desktop, and the subsequent relief upon discovering the SSTab ActiveX control
which superceded it. The pain returned with eVB as I developed my first tab-based
application, because the TabStrip object doesn't actually act as a container for
controls and you end up having to add extra code to manage the Visible or ZOrder
property of forms or frames (see other articles in www.devbuzz.com for ideas).
-
Databases are a staple favourite for pocket-size PC developers, due largely to
the fact that there [still] is no database component in Pocket Office. ADOCE is
the CE equivalent of ADO for the desktop, and if you already know ADO then you'll
be connecting to your data in no time. Be aware, though, that it is only gives
you a tiny subset of the desktop implementation, and you are advised to spend
time reading the excellent section on ADOCE in the online help.