Known Issues With Porting From eVC
A number of C++ tools and resources are available to help you convert your existing Embedded Visual C++ projects to Visual Studio 2005. For more information, see.
The Active Template Library (ATL), Microsoft Foundation Classes (MFC), and standard C++ libraries have been updated and changed since eVC. Some classes are not supported anymore. See. Code that calls these classes needs to be modified to compile in Visual Studio 2005. The following issues commonly arise when porting from eVC.
The CCeSocket::OnReceive() method does not get called in MFC for devices newer than CE 3.0.
The resolution is detailed at: http://support.microsoft.com/default.aspx?scid=kb;en-us;253945.
Theclass is not supported.
Many eVC projects contain references to CArchive Class class. To work around this, you need to remove references to CArchive.
Certain collection classes including CObArray, CMapPtrToPtr, and so on, are implemented in CE 5.0 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 work around 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)
Embedded Visual C++ version 4.0, by default, sets dialog style to DS_MODALFRAME for MFC Pocket PC applications. In MFC 8.0, this style is not supported.
This section outlines some of the more common errors that you may encounter when you migrate your project from eMbedded Visual C++ to Visual Studio 2005. 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, select View Code, and then comment out the following line:
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 click Properties.
Click Linker. Edit the Ignore Specific Library property by adding OLDNAMES.LIB.
Standard C++ Library (SCL) and ATL have APIs that also exist 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 select 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 properly
You may experience an issue where resource strings from ported applications are not being separated properly. In Solution Explorer, right-click the project file, and click Properties. Under Configuration Properties, expand Resources, and then select 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 edit the code to use a #ifdef statement around the FONT declaration as shown in the following code example.
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
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