Developing Applications for an Auto PC

• 06/29/2006
• 22 minutes to read

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.

Contents

IntroductionAuto PC Hardware and SoftwareDevelopment Tools Required for Developing Auto PC ApplicationsUser Interface DesignRequired Tasks for All Auto PC ApplicationsUsing Optional FeaturesPreparing an Application for DistributionObtaining the Windows CE Platform SDK, Auto PC EditionFor 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.

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 HWND and 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.

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 TabStop properties, 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 IASControl interface, because IASControl contains 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 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:

• 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 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:

• Creating a class that inherits from the IASEventSink interface.
• Implementing COM methods in the IUnknown interface.
• Creating a token implementation of the IDispatch interface 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.

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 Support check 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 Support check 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.

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 open command 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.