Building and Debugging Visual C++ Device Projects

Building and debugging device projects is slightly different from building and debugging desktop projects.

Following is a list of building and debugging techniques:

  • By default, the threading model for device projects is Free. However, Windows CE does not fully support COM marshaling and associated definitions if the DCOM option is not chosen when you are building your CE OS image. Therefore, on certain CE platforms, the compiler may generate warnings about DCOM support and single and multithreading definition. This warning is to advise you to handle threading and synchronization in your own code. For example, when you compile an ATL device project, the compiler may issue a warning about defining _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA. This is also the case for scenarios such as creating COM objects, consuming Web services, and ATL COM objects on the Windows Mobile platform. You can define this flag in your main header file as follows for single-threaded objects: #define _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA. If your code is handling multithreading, you can safely ignore this warning. For more information about COM, DCOM, and threading models on Windows CE, see COM Threads and Processes and Component Services (COM and DCOM), in the Windows CE 5.0 documentation.

  • By default, native device applications are created by using static linking. You can add the following run-time DLLs to your Additional Files project property if you decide to switch to dynamic linking:

    • MFC applications release build configurations

      Add the following run-time DLLs to your Additional Files project property: msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;MFC80U.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • MFC applications debug build configurations

      Add the following run-time DLLs to your Additional Files project property: msvcr80d.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;MFC80Ud.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • ATL applications release build configurations

      Add the following run-time DLLs to your Additional Files project property: msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_PROGRAM_FILES%\<projectname>|0;

    • ATL applications debug build configurations

      Add the following run-time DLLs to your Additional Files project property: msvcr80d.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;atl80.dll|$(BINDIR)\$(INSTRUCTIONSET)\%CSIDL_PROGRAM_FILES%\<projectname>|0;

      For more information about Windows CE DLL loading, see Windows CE DLL loading LoadLibrary.

      Note

      Loading multiple DLLs, with the same name, at the same time, from different directories, for example \Windows\aDLL.dll and \Program Files\aDLL.dll, may cause unpredictable results. It is recommended that you load one copy of a DLL at a time or expect the first loaded DLL to be called.

The following are some additional considerations:

  • When porting to MFC 8.0 #, define _WIN32_WCE_PSPC. By default, this flag is not defined in MFC8.0.

  • The ARM4T option is not supported when targeting Pocket PC 2003 or Smartphone 2003 in the Compile For Architecture drop-down list. To find this list in the <project name> Property Pages dialog box, click Configuration Properties, click C/C++, click Advanced, and then select Compile For Architecture.

  • GAPI functions are usable in C++ but not in C. Including gx.h in your code only works from C++. If you are using GAPI in your code, do not compile with the /TC compiler option.

  • In MFC 8.0 for Devices, you control the creation and insertion of CommandBar. The CDialog::m_pWndEmptyCB member is no longer supported. This member was used to point to the empty CCommandBar Class, also named MenuBar on the Pocket PC, which was created for the dialog box, and you could reference it to insert your own MenuBar.

  • Checked::_strlwr_s, _strlwr_s_l, _mbslwr_s, _mbslwr_s_l, _wcslwr_s, _wcslwr_s_l, Checked::tcslwr_s, and Checked::gcvt_s are provided for platforms that use Windows CE.

  • The _WIN32_WCE_PSPC flag is no longer defined; you can use _WIN32_WCE_PSPC WIN32_PLATFORM_PSPC flag as a workaround.

  • For STL application porting, include <deque> instead of #include <deque.h>.

  • The IDE supports multiple platforms. When hosting MFC or ATL ActiveX objects in a device project in a dialog box resource, you should create and register an equivalent control in an equivalent desktop ActiveX project. The control can be added to the device dialog box template in the resource editor and run correctly. The desktop and the device versions of the ActiveX control should have the same GUID and design-time properties, such as background color.

See Also

Tasks

How to: Provision a Device in a Visual C++ Project

Concepts

Debugging and Deployment Settings for Visual C++ Device Projects

Debugging and Deployment Settings for Visual C++ Device Projects

Reference

Debugging, Configuration Properties, <Projectname> Property Pages Dialog Box (Devices)

Other Resources

Debugging Device Projects

Creating and Porting Visual C++ Device Projects

Developing Visual C++ Device Projects