Developing Applications for an Auto PC

API	Description
Address Book	Enables access to the Contacts database.
Audio manager	Controls the audio system.
Forms Manager	Manages forms that comprise an Auto PC application.
Positioning and Navigation	Device interface for positioning, navigation, and GPS.
Power Management	Supports power management.
Speech API (SAPI)	Controls speech and text to speech.
Tuner	Supports the AM/FM tuner.
Vehicle I/O	Enables access to vehicle maintenance and diagnostic data, and allows an application to control vehicle operations.
WAV-in	Handles audio sources.
WAV-out	Handles audio destinations.
Win32	Interface to the operating system.

Control	Example	Description
Canvas		Enables an application to draw a graphic on a control.
Cross hairs		Enables a user to set two-dimensional values.
Edit		Enables text editing.
Memory slider		Displays memory allocation data.
Navigational arrows		Indicates when the UP, DOWN, LEFT, RIGHT, or ENTER faceplate keys are enabled.
Play list		Sets and displays the current play list for a compact disc (CD).
Slider		Enables a user to set one-dimensional values.
Spin box		Cycles through available selections, such as letters, numbers, or months.
Tabber		Selects a tabbed position in a list.
Visual volume indicator		Enables selection of values, such as volume.

Control	Description
Clock	Displays a clock.
HTML	Displays HTML text.
Image menu	Manages a menu that uses images, rather than text strings, to display commands.
Label	Displays static text.
Power list box	Displays lists when used in combination with a spin box control and an edit control.
Progress	Displays the progress of a process.
Shell menu	Manages a shell menu object.

Option	Result
Multiple Forms Support	Creates an application with two forms and the capability to switch between the forms with a menu.
Help Support	Generates default Help for the application.
Speech/TTS	Creates a speech object for the application to use.
Radio Tuner	Enables the application to use the tuner API.
Audio Manager	Enables the application to use the audio manager API.

HTML	Description
<HTML></HTML>	Begins and ends the file.
<HEAD></HEAD>	Defines the file heading.
<TITLE></TITLE>	Defines the title for Help indexes and topics.
<BODY></BODY>	Defines the body of the file.
<IMG>	Positions bitmaps; Only the SRC and ALT attributes are supported.
<A HREF></A>	Jumps to topics from the Help index.
<MENU></MENU>	Lists the Help index jumps.
<LI></LI>	Lists each jump.
<BR>	Breaks a topic text line.
<TABLE></TABLE>	Creates a table.

Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Corporation

June 1999

Summary:Provides an overview on developing Auto PC applications. (15 printed pages). Includes a discussion on the platform for developing mobile device applications offered by Microsoft Windows CE.

Introduction Auto PC Hardware and Software Development Tools Required for Developing Auto PC Applications User Interface Design Required Tasks for All Auto PC Applications Using Optional Features Preparing an Application for Distribution Obtaining the Windows CE Platform SDK, Auto PC Edition For More Information

`Introduction`


The Auto PC is a complete information, productivity, and
entertainment system for an automobile. A speech interface makes it
easy to control this powerful in-dash device. Simple voice commands
let users organize phone numbers and addresses, automatically dial
a cellular phone, prompt an Auto PC for driving directions, and
control the high-end digital audio system.
Microsoft Windows CE for the Auto PC offers an exciting new
platform that allows a software developer to create compelling new
mobile device applications while capitalizing on the developer's
knowledge of Windows-based APIs and tools.
This article assumes the reader is familiar with: 

C or Microsoft Visual C++ programming.
Component Object Model (COM) programming.
The Microsoft Windows CE Platform Software Development Kit
(SDK).
This article provides an overview of the process of developing
an Auto PC application, and does not provide detailed information
about the programmatic elements used in that process. For
additional information about developing Auto PC applications,
documentation that contains detailed descriptions of programmatic
elements and code examples, and sample applications, see the
Microsoft Windows CE Platform SDK, Auto PC Edition.
This article discusses the following requirements and guidelines
for creating applications for an Auto PC: 

Required Auto PC hardware and software, including the Windows
CE for the Auto PC operating system
Required development tools
Guidelines for designing a good user interface
This article also discusses the following steps of the
development process: 

Using the elements required in all Auto PC applications
Creating a Forms Manager for an application
Using forms and controls in an application
Using the WCE Auto PC AppWizard to create an application that
contains all of the required elements
Creating an installation application and installation compact
disc (CD) for an application.
Finally, this article briefly introduces the optional features
that an application for an Auto PC can use, such as speech and
Help, and the APIs and other programming tools used to provide
these features.

Auto PC Hardware and Software
An Auto PC provides a single, integrated platform that supports
entertainment and information management, and provides an
automobile driver with an easy way to obtain information and
entertainment while staying focused on the task of driving.
An Auto PC offers these advantages for users: 

Windows CE for the Auto PC allows users to transfer information
to other computers using Windows CE–based operating systems.
Multiple original equipment manufacturers (OEMs), independent
hardware vendors (IHVs), and independent software vendors (ISVs)
support Auto PC hardware and software.
Windows CE for the Auto PC provides a user interface (UI)
specifically optimized for the vehicular environment, and includes
both graphical and speech-based UI elements.
An Auto PC has the following minimum hardware requirements: 

A 60 MIPS processor
A faceplate and required keys
A 3-bit color screen that measures 256 x 64 pixels
8 megabytes (MB) of random access memory (RAM)
8 MB of read-only memory (ROM)
A CompactFlash card slot
A compact disc read-only memory (CD-ROM) drive for data and
music
A four or more channel preamplifier
A microphone
A universal serial bus (USB) port
An infrared (IR) port
An AM/FM tuner
Windows CE for the Auto PC extends the Microsoft Windows CE
version 2.01 operating system to support features specific to an
Auto PC, such as positioning and navigation. Windows CE for the
Auto PC includes APIs adapted from Microsoft Win32 APIs.
The following table shows the APIs that Windows CE for the Auto
PC supports.



API
Description


Address Book
Enables access to the Contacts database.


Audio manager
Controls the audio system.


Forms Manager
Manages forms that comprise an Auto PC
application.


Positioning and Navigation
Device interface for positioning, navigation, and
GPS.


Power Management
Supports power management.


Speech API (SAPI)
Controls speech and text to speech.


Tuner
Supports the AM/FM tuner.


Vehicle I/O
Enables access to vehicle maintenance and
diagnostic data, and allows an application to control vehicle
operations.


WAV-in
Handles audio sources.


WAV-out
Handles audio destinations.


Win32
Interface to the operating system.




Development Tools Required for
Developing Auto PC Applications
Creating an application for an Auto PC requires the following
development tools: 

Microsoft Visual C++ version 6.0 development system
Microsoft Windows NT Workstation version 4.0 operating system,
to support emulation
Microsoft Windows CE Toolkit for Visual C++ version 6.0
Windows CE Platform SDK, Auto PC Edition
Windows CE for the Auto PC does not support Microsoft Foundation
Classes (MFC), Active Template Libraries (ATL), or Microsoft Visual
Basic.

User Interface Design
An Auto PC interacts with a user through speech commands and
auditory feedback, as well as key strokes and images on the
faceplate. Speech is the preferred interface because it enables a
user to focus on driving. Developers must provide for both kinds of
input and output.
An Auto PC application should follow these guidelines for user
interface design: 

The UI should be simple and nondistracting. If a task requires
focused attention, the application should disable the task while
the vehicle is in motion.
The graphics and text used by the application should be visible
at a glance, taking into consideration the angle and distance of
the driver in relation to the device.
The UI should combine color and shape to communicate
information, and should not use color as the only means of
communication because color perception varies.
The UI design should work in the range of light and audio
levels typically encountered when driving an automobile.
The developer should test the application in actual driving
conditions to ensure it does not distract the driver.

Required Tasks for All Auto PC
Applications
An Auto PC application is composed of at least three COM
objects: 

A Forms Manager object controls application-wide functionality
and the forms used in the application.
A Form object holds the controls for a screen.
A Control object is placed on a form and displays information
or receives user input.
The following diagram shows the architecture of an Auto PC
application, including the required COM objects.



All applications for an Auto PC must perform the following
operations: 

Create a message loop to send and receive messages from
application service routines
Create a Forms Manager to manage an application's forms
Create a form to contain controls comprising the visual user
interface
Add a simple control to the form, or create a custom control
Create a message sink to handle application messages
The following sections discuss some of these operations in
greater detail.
Creating a Forms Manager
An Auto PC application uses a Forms Manager to handle its forms,
even if it uses only one form. The Forms Manager provides focus
management, menus, help, and event sinks. An application creates a
Forms Manager object and then registers with the Forms Manager as a
started application.
Creating a Form
A form is an object that a developer customizes to create the
user interface for an application. A form contains a collection of
controls, such as slider controls, power list boxes, play list
controls, and tabber controls that display information on a screen.
A form performs the following activities for an Auto PC
application: 

Acts as a container of controls
Dispatches messages to controls
Manages input focus
Provides methods for controls to invalidate and update
themselves
Provides access to a device context so that a form can draw to
the screen
A form is used instead of a window manager to display
information on a screen. A form performs the same type of standard
Windows-based messaging tasks typically performed by 
HWNDand message loop procedures, including automatic
invalidation and message posting.
To create a form, an application: 

Creates a form object.
Initializes and starts the form.
Adds a title to the form.
Makes the form visible.
Using Controls
Windows CE for the Auto PC supports a set of standard Microsoft
ActiveX controls for use by application developers. Controls
provide basic UI elements from which a developer can create forms.
The controls are displayed in an Auto PC form and are managed by
the Forms Manager.
Using standard controls
Windows CE for the Auto PC has standard controls developed
specifically for the automobile environment. The following table
describes and shows illustrations of some of the standard
controls.

The following table describes additional standard controls.



Control
Example
Description


Canvas



Enables an application to draw a graphic on a
control.

Cross hairs



Enables a user to set two-dimensional values.

Edit



Enables text editing.

Memory slider



Displays memory allocation data.

Navigational arrows



Indicates when the UP, DOWN, LEFT, RIGHT, or ENTER
faceplate keys are enabled.

Play list



Sets and displays the current play list for a
compact disc (CD).

Slider



Enables a user to set one-dimensional values.

Spin box



Cycles through available selections, such as
letters, numbers, or months.

Tabber



Selects a tabbed position in a list.

Visual volume indicator



Enables selection of values, such as volume.



Control
Description


Clock
Displays a clock.


HTML
Displays HTML text.


Image menu
Manages a menu that uses images, rather than text
strings, to display commands.


Label
Displays static text.


Power list box
Displays lists when used in combination with a spin
box control and an edit control.


Progress
Displays the progress of a process.


Shell menu
Manages a shell menu object.



A developer can add a standard control to a form by creating an
instance of a control or by using a resource file.
An application that creates an instance of a standard control
should also: 

Obtain a pointer to the control interface.
Use property methods to configure such parameters as color,
size, and position of the control.
Assign a class message sink for the control to the form.
Add the control to a form.
When using a resource file to add a standard control,
constraint-based layout is supported. Constraint-based layout
enables a developer to program a UI that is more flexible than
possible when creating an instance of the control. When using
constraint-based layout, an application defines the control in a
resource file, and then loads the resource.
Auto PC standard controls support properties that can be set
when the control is initialized or at any time during its
existence. A number of commonly used properties have been defined
as part of the standard control interface. Each standard property
has associated get and put methods, except the 
HasUI, 
ID, and 
TabStopproperties, which are read-only and have no put
methods.
Designing custom controls
If none of the standard controls are sufficient, a developer can
define custom controls. A custom control must adhere to the ActiveX
Automation model; however, Windows CE for the Auto PC does not
support conventional ActiveX in-place activation and embedding.
A custom ActiveX control must do the following: 

Run on a form rather than a window.
Implement a dual interface.
Implement the 
IASControlinterface, because 
IASControlcontains methods that enable an application to
specify basic properties of the control, such as size, placement,
or color.
Pass pointers to the class message sink and event sink
interfaces to the control.
Register itself as an in-process server when initialized.
The dynamic-link library (DLL) that contains the custom control
must implement the 
IClassFactoryinterface to allow instantiation of the
control.
A developer can also develop control interfaces for the custom
control. These interfaces must follow the control guidelines, and
must be speech-enabled.
To use a custom control, an application must: 

Add the control to a form.
Initialize the control.
Instruct the parent form of the control to start the control so
the control can begin processing or displaying information.
Verify that the control has started.
Instruct the parent form of the control to shut down the
control.
When the parent form of a control shuts down the control, the
control should: 

Stop processing.
Release any resources that the control was using.
Release any reference counts that the control has on other
objects.
A control should not release itself until all external reference
counts on it have been released.
A control must expose get and put methods for all standard
properties. However, controls are required to fully implement only
the five standard properties: 
CLSID, 
Enable, 
HasUI, 
ID, 
Parent, and 
Visible.
Creating a Message Sink
To handle messages and events, the Forms Manager delivers a
control's event and message data through a sink attached to an
object when the application initializes. Many applications create
an event sink as part of the initialization process. An event sink
is an ActiveX object that exposes methods called by an OS to notify
an application that an event has occurred. When an application
thread calls the 
DispatchMessagefunction, the Forms Manager processes the
message, and then routes the message through the appropriate
application sink to the target control.
Windows CE for the Auto PC contains two sink interfaces: an
event sink interface and a class message sink interface. The event
sink interface delivers control commands, such as a WM_COMMAND
message. The class message sink interface delivers status messages,
such as a WM_ACTIVATE message. A message sink must be placed on any
object in a Forms Manager that requires a message. When you add a
control to a form, the control inherits the form's event sink
interface.
The Forms Manager first calls an application sink, then a
control sink, and finally a form sink. By calling sinks in this
order, the Forms Manager enables an application to make controls
into a subclass and override some OS default behavior.
An application creates an event sink class by: 

Creating a class that inherits from the 
IASEventSinkinterface.
Implementing COM methods in the 
IUnknowninterface.
Creating a token implementation of the 
IDispatchinterface to ensure compilation.
Implementing application-specific message handling.
Using the AppWizard
To simplify the task of creating an Auto PC application that
contains all of the required elements, the Windows CE Platform SDK,
Auto PC Edition provides the WCE Auto PC AppWizard. The wizard
allows a developer to specify a friendly name and a short name for
the application, and to specify names for the application class,
forms, and form classes. The following table describes the options
available in the wizard.



Option
Result


Multiple Forms Support
Creates an application with two forms and the
capability to switch between the forms with a menu.


Help Support
Generates default Help for the application.


Speech/TTS
Creates a speech object for the application to
use.


Radio Tuner
Enables the application to use the tuner API.


Audio Manager
Enables the application to use the audio manager
API.



The WCE Auto PC AppWizard creates the following items: 

All of the files necessary for the project
An application wrapper class and a class for each form the
wizard creates
An application icon, a resource file, and associated header
file
Help files, if you selected the 
Help Supportcheck box on the first page of the wizard
One or two forms that contain a simple text control, depending
on whether you chose the 
Multiple Forms Supportcheck box in the wizard
A menu to switch between the forms if the wizard created two
forms
If the developer sets the active Windows CE configuration and
the active configuration appropriately in Microsoft Visual Studio,
the application created by the wizard should compile and run
without error.

Using Optional Features
Windows CE for the Auto PC includes many features that
developers can choose to employ in applications. Two features that
are most commonly added to applications are speech and Help.
Speech
Windows CE for the Auto PC includes speech recognition and
text-to-speech (TTS) technologies. These technologies enable an
Auto PC to respond to user-spoken commands and provide verbal
feedback to the user. The voice-controlled UI enables hands-free,
eyes-free Auto PC operation.
Speech recognition and TTS are exposed on an Auto PC through the
Speech API (SAPI), which enables a developer to implement these
technologies in an application. SAPI facilitates communication
between an application and a speech recognition engine. Windows CE
for the Auto PC uses a subset of SAPI for discrete speech
recognition. Windows CE for the Auto PC also adds interfaces that
extend the SAPI features available for use in an automobile.
Speech recognition
Speech recognition resolves user-spoken commands into a control
for an application. Windows CE for the Auto PC uses discrete speech
recognition, which recognizes words delineated by pauses.
To perform speech recognition, an application requires: 

An audio source object to accept waveform input.
A speech recognition engine that resolves waveform input into
text.
A list of speech commands, called a 
grammar, supplied to the speech recognition engine.
The audio source object and speech recognition engine object are
included in Windows CE for the Auto PC. An application must provide
only the grammar to the speech recognition engine and handle the
results returned.
To enable speech recognition, an application must: 

Get the speech interface.
Create a voice menu and add words to initialize the application
grammar.
Create a sink to handle speech recognition messages.
To add words to a voice menu, an application can: 

Directly pass a resource identifier table when creating the
voice menu. 
-or- 
Add words individually. 
-or- 
Add words from a resource file.
Once an application has added words to the menu, the application
should: 

Associate the voice menu with a form in the application.
Handle the WM_SPCH_RECOG message in form's class message sink. 
-or- 
Handle WM_COMMAND messages in the form's event sink.
Text-to-speech
TTS resolves text into synthesized speech. An Auto PC can read
text using the TTS algorithms to determine phrasing, or an
application can adjust the phrasing that an Auto PC uses with
control codes.
Enabling TTS for an application provides verbal feedback to
users about an application. To enable TTS, an application: 

Obtains a speech interface.
Specifies the sentence to be read.
The application can create a sink to handle TTS messages.
Adding Help to an Application
Windows CE for the Auto PC allows developers to add user Help to
applications. Help consists of visual Help that displays on the
screen and voice Help through prerecorded speech or TTS. Visual
Help provides information on using applications and is available by
pressing the HELP key on the faceplate. Voice Help provides
information on using application speech commands, and is available
by saying 
What can I say?and 
Help.
Visual Help and voice Help are context-sensitive only. In visual
Help, the context is usually the entire screen, because the screen
has no focus to provide a specific context. Visual Help for a
context can contain an index of topics, and users can browse
available topics.
In voice Help, the context is the active speech commands. Voice
Help has two parts: long voice Help, which provides task-based
information on speech commands, and short voice Help, which
provides a list of available speech commands. Windows CE for the
Auto PC builds short voice Help automatically from prerecorded
speech templates installed for the active speech commands for an
application. Developers must provide long voice Help strings for
each available application speech command. Windows CE for the Auto
PC reads the strings for the active speech commands when the user
requests long voice Help.
Adding visual Help
To provide visual Help for an application, a developer must
create visual Help files, and then provide function calls to these
files for each form that requires Help. Windows CE for the Auto PC
uses a subset of standard HTML tags for authoring visual Help.
Using this subset ensures that visual Help displays correctly on an
Auto PC. Each topic or index is authored in a separate HTML file
with an .html extension. The following table shows the HTML tags
that visual Help supports.



HTML
Description


<HTML></HTML>
Begins and ends the file.


<HEAD></HEAD>
Defines the file heading.


<TITLE></TITLE>
Defines the title for Help indexes and topics.


<BODY></BODY>
Defines the body of the file.


<IMG>
Positions bitmaps; Only the SRC and ALT attributes
are supported.


<A HREF></A>
Jumps to topics from the Help index.


<MENU></MENU>
Lists the Help index jumps.


<LI></LI>
Lists each jump.


<BR>
Breaks a topic text line.


<TABLE></TABLE>
Creates a table.



There are two ways to implement visual Help in an application.
An application can associate a Help topic or index with an
application, or can associate a Help topic or index with a specific
form.
Adding voice Help
To provide voice Help for an application, a developer must
create long voice Help strings for each speech command available in
the application and include them in the application's resource
files. Additionally, the developer must create a prerecorded speech
template for each speech command by recording an 11-kHz, 8-bit mono
.wav file that states the speech command. The developer must also
install this .wav file in the Windows directory of the Auto PC
during installation of the application.
If an application uses a speech command that does not have a
speaker-independent template, the application must have the user
train the word. A developer can use CEIBuild to require that the
user train specified phrases when installing the application. For
more information about CEIBuild, see the section 
"Creating an Installation
Application"later in this article.
Additional Features
Windows CE for the Auto PC includes APIs that allow applications
to accomplish many other tasks. Applications can control audio
input and output through several APIs. The Audio Manager API
enables an application to coordinate audio devices and control to
flow of audio sources. The WAV-in and WAV-out APIs enable an
application to control foreground audio sources, and the Tuner API
enables an application to control the AM/FM tuner.
Other APIs include: 

The Address Book API, which enables an application to
manipulate the Contacts database on an Auto PC.
The Positioning and Navigation API, which enables an
application to obtain position data from a Global Positioning
System (GPS) receiver.
The Vehicle I/O API, which enables an application to obtain
vehicle maintenance and diagnostic data, and to control vehicle
operations, such as locking and unlocking doors.

Preparing an Application for
Distribution
There are two steps to preparing an application for
distribution: creating an installation application, and creating an
installation compact disc (CD).

Creating an Installation
Application
The Windows CE Platform SDK, Auto PC Edition, includes an
application called CEIBuild that allows developers to produce a
.cei file that installs the developer's application on an Auto PC.
Along with the CEIBuild, the Auto PC SDK contains the include (.h)
files necessary to create custom setup DLLs.
Using CEIBuild to create an installation application is highly
recommended, because using CEIBuild ensures the proper installation
and uninstallation of an application. In addition, the .cei file
must contain all files, directories, and registry entries that the
application uses. If the .cei file does not reference some of the
files, directories, or registry entries for an application, those
items will be lost during system recovery or upgrade.
A developer uses CEIBuild to add files and directories to the
object store on an Auto PC. To facilitate repeated cycles of
testing and fixing applications, CEIBuild maintains a link to the
original file to allow updating rather than re-creating
installation files when the source files change. A developer
defines how the installation process handles files when an existing
file is detected during installation onto the Auto PC using one of
the following options: 

Never replace if the file exists.
Always replace if the file exists.
Replace if newer (Default).
The Auto PC installation system supports registering COM objects
during installation. When a developer adds a DLL that has the
DllRegisterServer and DllUnregisterServer entry points, CEIBuild
automatically flags the component for self-registration. A
developer can also designate .exe files as self-registering. The
Auto PC Load program, which reads and executes the data stored in
the .cei file generated by CEIBuild, calls the registration entry
point or starts the executable program with the /REGSVR
registration switch. The Auto PC Load program calls or starts the
.dll or .exe file to allow the update of registration information
when the application is removed.
Using CEIBuild also provides support for the following: 

Creating a shell shortcut for the application during
installation.
Providing and updating a version number for the application.
Maintaining a reference count for files or directories that the
user attempts to install on multiple occasions.
Specifying a speaker-independent template file for installation
with the application.
Specifying a text phrase that the user must train during
installation if CEIBuild does not install a speaker-independent
template.
Saving dynamic data and registry information used by the
installed application.
Creating an Installation CD
To create an installation CD for an application, a developer
must copy the following files to the CD: 

An Autorun.inf file that opens the .cei file
A .cei file containing your application files
Writing an Autorun script
The syntax of the AutoRun.inf file is similar to that of Win32
desktop computers, but uses an Auto PC-specific section header to
allow one piece of installation media to contain autorun components
for both desktop operating systems and the Auto PC. To include
desktop support, use the standard desktop sections like
[autorun].
A developer places an Autorun.inf file in the root of the
installation media, either CD or CompactFlash card. Windows CE for
the Auto PC looks for the following section names of the
Autorun.inf file:
[AutoPC] [AutoPC.shx]
If Windows CE for the Auto PC finds a section for the specific
Auto PC device processor, the operating system (OS) uses that
section and all others are ignored. If the OS does not find a
matching section for the specific processor family, the OS uses the
generic [AutoPC] section.
A developer installs the .cei file for an application by: 

Placing the application's .cei file in the root directory on
the installation media.
Creating an Autorun.inf that includes an 
opencommand line that refers to the .cei file in an Auto
PC-specific section.

Obtaining the Windows CE Platform SDK,
Auto PC Edition
A preview release of the Windows CE Platform SDK, Auto PC
Edition is currently available from this 
Microsoft Web site.

For More Information
For more information about Windows CE for the Auto PC and about
developing applications for an Auto PC, see the Windows CE Platform
SDK, Auto PC Edition documentation
and the Windows CE Platform SDK documentation. For more
information on writing ActiveX controls, see 
"How to Write and Use ActiveX Controls for
Windows CE.".
For the latest information about Windows CE application
development and embedded development tools, visit the Windows
Embedded Developer Center at 
http://msdn.microsoft.com/embedded/. Additional
articles are available at these Web sites, describing other
features of Windows CE.

The information contained in this document represents the
current view of Microsoft Corporation on the issues discussed as of
the date of publication. Because Microsoft must respond to changing
market conditions, it should not be interpreted to be a commitment
on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of
publication. This document is for informational purposes only.


This White Paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.


© 1999 Microsoft Corporation. All rights reserved.


Microsoft, ActiveX, Visual Basic, Visual C++, Visual J++, Win32,
Windows, and Windows NT are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or
other countries.


Java is a trademark of Sun Microsystems, Inc.


Other product and company names mentioned herein may be the
trademarks of their respective owners.









© 2004 Microsoft Corporation. All
rights reserved.

Developing Applications for an Auto PC

Contents

Introduction

Auto PC Hardware and Software

Development Tools Required for Developing Auto PC Applications

User Interface Design

Required Tasks for All Auto PC Applications

Creating a Forms Manager

Creating a Form

Using Controls

Using standard controls

Designing custom controls

Creating a Message Sink

Using the AppWizard

Using Optional Features

Speech

Speech recognition

Text-to-speech

Adding Help to an Application

Adding visual Help

Adding voice Help

Additional Features

Preparing an Application for Distribution

Creating an Installation Application

Creating an Installation CD

Writing an Autorun script

Obtaining the Windows CE Platform SDK, Auto PC Edition

For More Information

`Introduction`