Customizing the Windows CE .NET User Interface, Part 2

（引自：http://msdn.microsoft.com/en-us/library/aa459149.aspx）

Customizing the Windows CE .NET User Interface, Part 2
Mike Hall

Microsoft Corporation
Steve Maillet

Entelechy Consulting
May 1, 2002
Download Ieshell.exe.
Last
month we took a look at customizing certain user interface features of
the Microsoft® Windows® CE .NET operating system. This month we extend
this to cover building a custom shell using the Microsoft® Windows CE
Internet Explorer. Of course, the same process could be used to create
a custom shell using a stand-alone application.

Custom Shells

The
Explorer shell provided with Platform Builder is a good general-purpose
shell that allows users a great deal of flexibility, while maintaining
a generally familiar look and feel. Many embedded devices require a
more tightly controlled user experience; for example, HMI industrial
controllers, self-service Kiosks, or possibly even the control system
of the train I'm riding in as I write this. These types of systems
require a custom shell that limits the device to a particular function
or set of functions it was designed for. Fortunately, Windows CE was
designed with this in mind, and allows you to use any application you
want as the shell.
Let's look at some of the functionality a custom shell might need:

Start up at boot time.
Present user with an interface.
Receive user input (and act on it).
Display response to user.
Display current status of some operation(s).

Change modes/Tasks.

Starting the Shell at Boot Time

Starting
the shell at boot time is pretty easy—it's just a registry entry. The
following extract from the registry shows how the standard shell
(explorer.exe is loaded):


Copy Code

[HKEY_LOCAL_MACHINE/init]
"Launch50"="explorer.exe"
"Depend50"=hex:14,00, 1e,00

After the kernel initializes, it scans the Init
key looking for value entries of the form "LaunchXX" and loads the
application listed in numerical order. The DependXX values specify the
XX value of an application loaded by the kernel as binary values in the
registry. (The "hex:" syntax is used in REG files for values of type
REG_BINARY.) The data for this registry value is a set of DWORD values
corresponding to the Launch values of other applications the program
depends on.
Note [/b]The
data is defined as a sequence of bytes, so you must take into account
that the operating system expects the data in little-endian order. So the example translates to:
Launch
explorer.exe after whatever application is listed as "Launch20" and the
application listed as "Launch30." (These happen to be Device.exe and
Gwes.exe.)
There is a catch in this mechanism. The dependency is
designed for operating system dependent services. The device manager
and GWES must actually have initialized to a point where they can be
used before the shell can start using them. Therefore, the operating
system can't just launch the applications randomly. (Well, actually it
could, but that would leave each application to create its own
mechanism for indicating it was ready for use—creating general havoc
for developers the world over.) Fortunately, the Windows CE architects
considered this and created a standard mechanism for indicating that an
application is ready for use. Windows CE uses this mechanism to
determine when it should launch the dependent applications. Any
application loaded by the Init key should call SignalStarted(), with the command line of the application converted to a long integer as in the following example:


Copy Code

SignalStarted(_wtol(lpCmdLine));

This call informs the operating system that the
application has initialized itself to a point where it can now be
relied upon for use by other applications.

Using the Browser as a Shell

Once
you have gotten your application to load at boot time in place of the
shell, it's time to get busy with the UI coding. Typically, a UI in
embedded devices doesn't resemble the traditional Windows application,
with its main window and menu, toolbars, status bar, and so on.
Instead, an embedded device UI is usually quite visual, and often best
created by professional graphics designers. (Most engineers don't even
come close to that!) So it's often desirable for the programmer and
graphics designer to work together. Such a meeting of minds is proving
very successful in Web development and design. Fairly rich, visually
pleasing interfaces are generated almost daily on the great WWW. Why
not use that model in your embedded system UI design? Windows CE .NET
includes a browser component that let's you do just that.
The
browser component in Windows CE .NET is a subset of the Microsoft®
Internet Explorer 5.5 browser control on the desktop. This component is
a Microsoft ActiveX® control that provides all the browsing and
rendering functionality in one reusable package. There is also a sample
hosting application called IESAMPLE. (We'll be using that later on.)
The
IESAMPLE application, which hosts the Internet Explorer browser
control, provides a familiar Internet Explorer browser interface
complete with menus, toolbars, and status bar. However, as previously
mentioned, this isn't desirable in most embedded systems. What we need
to have is an application that can use the browser in a "Full Screen"
mode. Well it just so happens that the good folks at Microsoft thought
of that, too. (Although, they failed to mention it in the
documentation!) The IESAMPLE application includes a number of #if tests
to enable or disable the menus, status bar, and favorites. So you only
need to make a few minor modifications to the build of IESAMPLE to get
what you need for a browser-based shell.

Setting Up the Project

First, download the source for the project IESHELL.exe, using the link at the top of this article.
The
IESAMPLE application is located in _WINCEROOT/public/Internet
Explorer/oak/IESAMPLE. As we've discussed in previous articles, it's
generally not a good idea to modify the Microsoft provided code off the
COMMON directory or any of the standard configurations. So you can copy
the IESAMPLE files to a folder under your platform's workspace folder
(that is, _WINCEROOT/MyDevice/IESHELL). IESAMPLE is set up to build
using a SOURCES file. You can create a new blank Platform Builder
project and add the files in the IESHELL folder you copied everything
into. The easiest way to do this is to right-click on the project in
the file view and click Add files to project. (Add everything
except the 'SOURCES' and 'MAKEFILE' and options.cpp. Be sure to use the
*.* filtering when adding files to the project to get the various
resource files as well.)
Because the project was originally
created using a SOURCES file, there are some extra settings you will
need to make to the project before it will build correctly.
First, you will need to add the path to the ATL headers on the C/C++ tab under the Preprocessor category. (Be sure to click All Configurations so that the settings apply to each of the project configurations.)


Figure 1. Add the ATL include folders From the same tab in the ProjectSsettings dialog, click the Precompiled Headers category and click the IESHELL
project in the left side tree view. This will change the settings for
all files in the project. The precompiled header is PRECOMP.H, so all
files should be set to use it.


Figure 2. Setting the precompiled header Next, click the stdafx.cpp file in the tree view to alter its settings to generate the pre-compiled header information through precomp.h.


Figure 3. Setting the precompiled header for stdafx.cpp Next, click the IESHELL project in the tree and then click the Link tab. You will need to add the following libraries to the input libraries (note that they are separated by a space):


Copy Code

ole32.lib oleaut32.lib commctrl.lib uuid.lib wininet.lib winsock.lib

Figure 4. Adding additional required libraries Then, on the Link tab, click the Output category, and set the entry point to WinMain, the Stack size to 0x20000, and the commit size to 0x1000.


Figure 5. Setting the reserve and commit sizes The
SOURCES file uses the RCADDNULL option, which adds a '/0' to the end of
all resource strings, so they can be used directly with LoadString().
Unfortunately, there aren't any settings options for that directly in
the IDE, so you will need to adjust the resource compiler settings to
use the /n parameter manually in the Project Options. Click the Resources tab, and click the IESHELL
project in the tree, so that the settings are made project wide for all
RC files. The Project Options field is only editable when you have a
single configuration selected, so you will need to make this adjustment
for each configuration.


Figure 6. Adjusting the resource complier settings Add the following to the top of the PRECOMP.H file:


Copy Code

#define NO_FAVORITES
#define NOCOMMANDBAR
#define NOSTATUSBAR
#define NOOFFLINE
#define NOFIND
#define NOOPTIONS

#include "defines.h"

defines.h is needed to make sure some definitions
are available even if the other headers and features are disabled by
the NOxxxx defines. The NOxxxx defines could be set in the project
settings dialog as another option. You must also comment out or remove
the #include<pkfuncs.h> (Line 44), as it is not actually needed.
You'll need to make some changes in MainWnd.cpp as well:

Replace all occurrences of IESAMPLE with IESHELL.
Replace the lines 190-193 with the following code to handle the SignalStarted() call:


Copy Code

// allow launching with command line arg
// for development purposes. When loaded
// from the init key initSignal will be non zero
int initSignal = _wtol(lpCmdLine);
if(initSignal!=0)
{
SignalStarted(initSignal);
if(HandleNewWindow2(_T(""), NULL))
{
goto Cleanup;
}
}
else
if(HandleNewWindow2(lpCmdLine, NULL))
{
goto Cleanup;
}

At the top of CMainWnd::~CMainWnd(), place an #ifdef block around the command bar support.


Copy Code

#ifndef NOCOMMANDBAR
if(_himlCmdBand)
ImageList_Destroy(_himlCmdBand);
#endif

In CMainWnd::MainWndProc(), move the #endif // NOCOMMANDBAR down to enclose both the WM_COMMAND and the WM_NOTIFY message.
At the bottom of CMainWnd::Close(), enclose the command bar code in an #ifdef NOCOMMANDBAR block as follows:


Copy Code

#ifndef NOCOMMANDBAR
if(_himlCmdBand)
{
ImageList_Destroy(_himlCmdBand);
_himlCmdBand = NULL;
}
#endif  //NOCOMMANDBAR

Next, you will need to add some build
actions to get things going. You can use any HTML and image files you
need for your own UI. We've provided a simple sample of what a WebPhone
device might look like. At this point it would be appropriate to remind
you that it's rare to find a software engineer who is also a good
graphics designer. (This sample is no exception!) The major advantage
of using the browser as the shell of a dedicated device is the
separation of presentation from functionality. The DHTML can contain
ActiveX objects that implement the core functionality of the device and
are manipulated by Microsoft JScript® code to connect the UI to the
primary device functionality.
To set the actions for the sample, from the Feature View, you will need to right-click the IESHELL.PBP and select settings from the popup menu. Click All Configurations and Pre-Make Image for the Build Step. Click New to create a new action to copy C:/WINCE400/PUBLIC/MyPad/IESHELL/Files/IESHELL.reg to the $(_FLATRELEASEDIR).
In the Make Image step, add an environment variable IMGIESHELL and set it to 1.
The
registry file will be copied to the release directory and processed by
the makeimg tool. IESHELL.REG is set up to test for the Environment
variable IMGIESHELL, conditionally include the settings to launch
IESHELL.EXE as the shell, and to specify the default home page.


Figure 7. Copying the IESHELL registry file to the _FLATRELEASEDIR Click the BIB Info tab.
Add any file; you can then edit the entry in the dialog to
$(_FLATRELEASEDIR)/IESHELL.EXE, but be sure it's in the Modules section
and is not compressed. Then add each of the files listed below as
uncompressed in the Files section. These are the images and home page
(shell.htm) for the HTML-based shell:


Copy Code

BKG.jpg
Button0.jpg
Button1.jpg
Button2.jpg
Button3.jpg
Button4.jpg
Button5.jpg
Button6.jpg
Button7.jpg
Button8.jpg
Button9.jpg
ButtonPOUND.jpg
ButtonSTAR.jpg
default.htm
dir.txt
homelogo.gif
IESHELL.BIB
IESHELL.reg
Shell.htm

Figure 8. Adding files to BIB Info Making the start page and the elements it loads uncompressed helps the page to load faster.
Once
you have all of the changes and settings taken care of, you can build
the project and see the result. It should look like the following:


Figure 9. The end result: an Internet Explorer shell for Windows CE It
doesn't really do anything particularly useful, but it does show how to
set up a UI based on the browser. You can further enhance the
functionality to support a set of navigation buttons for the
mini-browser window, and even include an address bar. If you are really
ambitious, you can enhance it to utilize the support available in
Windows CE .NET for Voice over IP and Real-Time Communications.

Get Embedded
Mike Hall
is a Product Manager in the Microsoft Embedded and Appliance Platform
Group (EAPG). Mike has been working with Windows CE since 1996—in
developer support, Embedded System Engineering, and the Embedded
product group. When not at the office, Mike can be found with his
family, working on Skunk projects, or riding a Honda ST1100. Steve Maillet
is the Founder and Senior Consultant for Entelechy Consulting. Steve
has provided training and has developed Windows CE solutions for
clients since 1997, when CE was first introduced. Steve is a frequent
contributor to the Microsoft Windows CE development newsgroups. When
he's not at his computer burning up the keys, Steve can be found
jumping out of airplanes at the nearest drop zone.