Udostępnij za pośrednictwem

Known Issues with Porting From eMbedded Visual C++

  • Artykuł

A number of C++ tools and resources are available to help you convert your existing eMbedded Visual C++ projects to Visual Studio. For more information, see eMbedded Visual C++ to Visual Studio Upgrade Wizard.

The Active Template Library (ATL), Microsoft Foundation Classes (MFC), and standard C++ libraries have been updated and changed since the introduction of eMbedded Visual C++. For a list of classes that are not supported, see List of eVC Classes Not Supported from MFC 3.0 to 9.0. Code that calls these classes has to be modified to compile in Visual Studio. The following issues generally occur when you are porting from eMbedded Visual C++.

Issue

Description/Resolution

The CCeSocket::OnReceive() method does not get called in MFC for devices newer than Windows CE 3.0.

The resolution is discussed in the Help and Support Knowledge base article: Bug: CCeSocket OnReceive() does not get called for accepted data sockets.

The CArchive Class class is not supported.

Many eMbedded Visual C++ projects contain references to CArchive Class class. To resolve this issue, you must remove references to CArchive.

Certain collection classes, such as CObArray, CMapPtrToPtr, and so on, are implemented in Windows CE 5.0 by using templated versions of CArray<>, CMap<>, and so on. In eMbedded Visual C++ version 4.0 and in desktop C++ libraries, these types are implemented as regular, non-templated classes. Therefore, calling IMPLEMENT_SERIAL on these templated classes causes a compilation error:

error C2039: 'classCObArray' : is not a member of 'CArray<TYPE,ARG_TYPE>'

error C2065: 'classCObArray' : undeclared identifier

To resolve this difference in implementation, change your IMPLEMENT_SERIAL macro to use CObject instead of CObArray, CMapPtrToPtr, and so on.

In other words, do not write this:

IMPLEMENT_SERIAL(CYourClass, CObArray, 0)

Use this instead:

IMPLEMENT_SERIAL(CYourClass, CObject, 0)

By default, eMbedded Visual C++ version 4.0, sets dialog style to DS_MODALFRAME for MFC Pocket PC applications. In MFC 9.0, this style is not supported.

Examples

This section outlines some of the more common errors that you might encounter when you migrate your project from eMbedded Visual C++ to Visual Studio. For more information, see Migrating Microsoft eMbedded Visual C++ Projects to Visual Studio 2005.

  • Compile error: Cannot open include file 'wceres.rc'

    Right-click the project resource (RC) file, click View Code, and then comment out the following line:

    //#include "wceres.rc"

  • NUM_TOOL_TIP not defined

    In your header file, define #define _WIN32_WCE_PSPC for your Pocket PC configurations and _WIN32_WCE_WFSP for your Smartphone configurations.

  • Cannot open file OLDNAMES.lib

    In Solution Explorer, right-click the project file, and then click Properties.

    Click Linker. Edit the Ignore Specific Library property by adding OLDNAMES.LIB.

  • Ambiguous Overload

    Standard C++ Library (SCL) and ATL have APIs that also are in the device SDK. Disambiguate with a namespace, such as ::.

  • Module Machine type 'THUMB' conflicts with target machine type 'ARM

    In Solution Explorer, right-click the project file, and then click Properties.

    Under Configuration Properties, expand Linker, and then click the Command Line property. Remove the /MACHINE:THUMB switch from the command line for each Windows Mobile 5.0 configuration in the Property pages.

  • Resource String not separated correctly

    You may experience an issue where resource strings from ported applications are not being separated correctly. In Solution Explorer, right-click the project file, and then click Properties. Under Configuration Properties, expand Resources, and then click the Command Line property. Add an -n switch to the resource compiler command line.

  • BEGIN expected in dialog error

    This error is usually followed by File not found errors, such as "file not found: 0x1". Go to the RC file that is indicated by the error, and modify the code to use a #ifdef statement around the FONT declaration as shown in the following code example.

    Original code:

    IDD_COMPTEST DIALOGEX 0, 0, 186, 95
STYLE DS_SETFONT | WS_CHILD
EXSTYLE WS_EX_CONTROLPARENT
FONT 8, "MS Sans Serif", 0, 0, 0x1
BEGIN
END

    Modified code:

    IDD_COMPTEST DIALOGEX 0, 0, 186, 95
STYLE DS_SETFONT | WS_CHILD
EXSTYLE WS_EX_CONTROLPARENT
#ifdef _WIN32_WCE
FONT 8, "MS Sans Serif"
#else
FONT 8, "MS Sans Serif", 0, 0, 0x1
#endif
BEGIN
END

See Also

Concepts

eMbedded Visual C++ to Visual Studio Upgrade Wizard

Other Resources

Windows Mobile Platform Migration FAQ for Developers