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
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:
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:
This article also discusses the following steps of the development process:
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.
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:
An Auto PC has the following minimum hardware requirements:
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. |
Creating an application for an Auto PC requires the following development tools:
Windows CE for the Auto PC does not support Microsoft Foundation Classes (MFC), Active Template Libraries (ATL), or Microsoft Visual Basic®.
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:
An Auto PC application is composed of at least three COM objects:
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:
The following sections discuss some of these operations in greater detail.
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.
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:
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 HWND and message loop procedures, including automatic invalidation and message posting.
To create a form, an application:
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.
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.
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. |
The following table describes additional standard controls.
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:
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 TabStop properties, which are read-only and have no put methods.
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:
The dynamic-link library (DLL) that contains the custom control must implement the IClassFactory interface 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:
When the parent form of a control shuts down the control, the control should:
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.
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 DispatchMessage function, 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:
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:
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.
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.
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 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:
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:
To add words to a voice menu, an application can:
-Or-
-Or-
Once an application has added words to the menu, the application should:
-Or-
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:
The application can create a sink to handle TTS messages.
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.
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.
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.
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:
There are two steps to preparing an application for distribution: creating an installation application, and creating an installation compact disc (CD).
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:
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:
To create an installation CD for an application, a developer must copy the following files to the CD:
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:
A preview release of the Windows CE Platform SDK, Auto PC Edition is currently available at http://www.microsoft.com/windowsce/. The final release of the Windows CE Platform SDK, Auto PC Edition version 1.0 will be available at the same site.
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, visit the Windows CE Toolkit Web site at http://msdn.microsoft.com/cetools/. For information about embedded development tools, visit the Windows CE developer site at http://www.microsoft.com/windowsce/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.