Microsoft Visual C++ Guide(在window下用vc编译wxWidget)

Microsoft Visual C++ Guide

From WxWiki

(Redirected from MSVC)

Jump to: navigation, search

This guide outlines the steps for building the wxWidgets library, building and running the included samples, and outlines two separate ways of setting up your own project (the first by hand, and the second by copying one of the wxWidgets sample projects). This is an informal, complementary guide to the official wxWidgets MSW installation docs included with wxWidgets at docs/msw/install.txt (which can also be found online), please read all of the "Microsoft Visual C++ compilation" section before following this guide for important installation notes not covered here. If you run into any problems, check the troubleshooting section first, then all of the wxWidgets FAQs, and failing those, you can try the mailing lists, forums, or IRC.

[edit] Version Information

Visual C++ 6.0 

Released in 1998.

Visual C++ .NET 2002 (7.0) 

First edition of Visual C++ to include managed extensions to the C++ language shared with Visual Basic and Visual C#. This version was known to contain some major bugs at release, and it's highly recommended developers either stick with 6.0 (since wxWidgets does not use the managed extensions anyway) or upgrade to at least 7.1.

Visual C++ .NET 2003 (7.1) 

Released as a major upgrade to 7.0 fixing a number of issues. The compiler and linker were released for free in the Visual C++ Toolkit 2003 (which has now been taken down in favor of using Visual C++ 2005 (8.0) Express Edition).

Visual C++ 2005 (8.0) 

This version contains a few improvements to Intellisense and additional STL debugging features. The Express Edition is available for free, even for commercial use.

Visual C++ 2008 (9.0)

The latest current release of Visual C++. As opposed to 2005, the Express Edition of this version includes the Windows Platform SDK making it much easier to setup applications built on wxWidgets than in 2005.

It is highly recommended that you use Visual C++ 2008 (9.0), but wxWidgets is compatible with every version of Visual C++ listed above if you need to use an older version for some reason. The instructions below apply to all versions of Visual C++ from 6.0 to 9.0. Be sure to check the troubleshooting section for known version specific issues if you run into any.

If you don't already have a version of Visual C++ installed, Visual C++ 2008 Express Edition is available for free, including for commercial use.

[edit] Getting Started

wxWidgets is available for download in multiple flavors for the Windows platform. There is a wxMSW setup executable that will install wxWidgets for you, as well as multiple archive formats containing everything needed in the wxMSW packages. Additionally, the wxAll packages include the source for all supported platforms. (Be sure to check the troubleshooting section if you are using wxALL, CVS or daily snapshot sources). You only need one of these downloads. If you downloaded one of the archive formats, installing it is as easy as unpacking it and moving the root folder where ever you want it to be installed.

If you used the installer, in addition to installing the wxWidgets source files, it also automatically adds a WXWIN environment variable on your system pointing to the location where you installed wxWidgets. It isn't necessary to have this environment variable setup, however it is highly recommended that you do so if you didn't use the installer. To setup the WXWIN environment variable by hand follow these steps:

1. Close all instances of Visual C++ or your new environment variables will not be available until you restart Visual C++.
2. Right-click on My Computer and open the Properties window.
3. Switch to the Advanced tab and click the Environment Variables button.
4. Under the 'User variables' section, click New.
5. For name, type "WXWIN", and for value, type the full location where you installed wxWidgets to (typically "C:/wxWidgets-x.x.x").
6. Click OK on all dialogs to save your settings.

The wxWidgets project files distributed for Visual C++ are currently saved in the Visual C++ 6.0 file format. If you are using a version of Visual C++ other than 6.0, you will be asked about converting the project files for the version you are using. This is expected behavior, and you can safely answer "Yes To All" when opening any of the project or workspace files. The files are saved in the 6.0 format simply for backwards compatibility, and will work in all version of Visual C++ from 6.0 to 8.0.

wxWidgets contains two separate Visual C++ workspaces used to build wxWidgets using MSVC: "build/msw/wx.dsw" and "build/msw/wx_dll.dsw". The first has subproject dependency information setup for use when building static libraries, and the second is setup for building dynamic libraries. Both contain configurations for static and dynamic libraries, but you may run into problems building those configurations using the wrong workspace.

Keeping the information above in mind, you are now ready to open the wxWidgets workspace file of your choice, and compile the wxWidgets library. Once opened (and converted if necessary), the wxWidgets workspace contains multiple configurations for all subprojects. If you are not familiar with what these are or how they work, please read the next section before continuing onward.

[edit] wxWidgets Build Configurations

All build configurations represent pre-configured settings for building wxWidgets in either ANSI or Unicode mode, Debug or Release, Static or Dynamic libraries, as well as separate configurations for building either wxMSW or wxUniversal. Each one of these will result in different libraries being built in different file locations. Here's a brief explanation of each of these modes:

• ANSI/Unicode: If building with Unicode support, wxWidgets will use Unicode strings with all components, and will automatically set the type of all literal strings properly wrapped with the string translation functions [_T(""), _(""), wxT("")] as wide character Unicode strings. See the Unicode Overview for more information.
• Debug/Release: Building in debug mode will result in libraries with debug symbols (useful when using a debugger) as well turn on the functionality of all helpful debugging functions and macros and prompt the user upon reaching assertions. You will almost always have a need for both debug and release configurations. See the Debugging Overview for more information.
• Static/Dynamic: Unless a configurations is labeled with "DLL", it is a static library configuration. Static libraries are linked directly into your program's executable when compiled while dynamic libraries are released as separate DLL files that your program links to dynamically at runtime. If you are unsure about which to use, build the static libraries.
• Universal: This is a port of wxWidgets (also referred to as "wxUniversal") which implements the various GUI controls by drawing them itself (using low level wxWidgets classes). It is implemented on most platforms and will result in your program looking identical on all platforms much like using Java or GTK+. Most wxWidgets users use wxWidgets because of its ability to build native looking applications, so this is rarely used, rarely worked on, and only implements a small subset of the wxWidgets library. Do not use Universal configurations unless you know what you are doing. See the "docs/univ/readme.txt" file for more information (also available online).

[edit] Ensure correct linking

wxWidgets can be built with either Multi-threaded (/MT) or Multi-threaded DLL (/MD) setting (these can be set from project properties). Ensure that your whole project uses the same settings. The default project file uses /MD, so you have to recompile with /MT if your project uses the latter.

If you get a missing _timezone symbol problem, see http://sourceforge.net/tracker/index.php?func=detail&aid=1904863&group_id=9863&atid=109863 .

Replace

#elif defined(__WXWINCE__) && defined(__VISUALC8__)

with

#elif defined(__VISUALC8__)

on line #172 of datetime.cpp to fix this.

[edit] Library Files

Refer to this table for the filenames of the libraries needed later when building your application based on the configurations desired. The libraries listed here correspond to those described in the Libraries List in the official manual. Add the ".lib" extension to the filename for static builds and ".dll" for dynamic builds. If you are not using wxWidgets 2.8, replace the "28" in the filename with the version of wxWidgets you are using (ie: "26" if using 2.6).

Library	Debug		Release
	ANSI	Unicode	ANSI	Unicode
wxMSW
wxBase	wxbase28d	wxbase28ud	wxbase28	wxbase28u
wxNet	wxbase28d_net	wxbase28ud_net	wxbase28_net	wxbase28u_net
wxODBC	wxbase28d_odbc	wxbase28ud_odbc	wxbase28_odbc	wxbase28u_odbc
wxXML	wxbase28d_xml	wxbase28ud_xml	wxbase28_xml	wxbase28u_xml
wxAdvanced	wxmsw28d_adv	wxmsw28ud_adv	wxmsw28_adv	wxmsw28u_adv
wxAUI	wxmsw28d_aui	wxmsw28ud_aui	wxmsw28_aui	wxmsw28u_aui
wxCore	wxmsw28d_core	wxmsw28ud_core	wxmsw28_core	wxmsw28u_core
wxDbGrid	wxmsw28d_dbgrid	wxmsw28ud_dbgrid	wxmsw28_dbgrid	wxmsw28u_dbgrid
wxGL	wxmsw28d_gl	wxmsw28ud_gl	wxmsw28_gl	wxmsw28u_gl
wxHTML	wxmsw28d_html	wxmsw28ud_html	wxmsw28_html	wxmsw28u_html
wxMedia	wxmsw28d_media	wxmsw28ud_media	wxmsw28_media	wxmsw28u_media
wxQA	wxmsw28d_qa	wxmsw28ud_qa	wxmsw28_qa	wxmsw28u_qa
wxRichText	wxmsw28d_richtext	wxmsw28ud_richtext	wxmsw28_richtext	wxmsw28u_richtext
wxXRC	wxmsw28d_xrc	wxmsw28ud_xrc	wxmsw28_xrc	wxmsw28u_xrc
Optional Internal Libraries (each released under different licenses):
Expat XML Parser	wxexpatd	wxexpatd	wxexpat	wxexpat
libjpeg (JPEG Group)	wxjpegd	wxjpegd	wxjpeg	wxjpeg
libpng	wxpngd	wxpngd	wxpng	wxpng
Modified Tcl Regex	wxregexd	wxregexud	wxregex	wxregexu
libtiff	wxtiffd	wxtiffd	wxtiff	wxtiff
zlib	wxzlibd	wxzlibd	wxzlib	wxzlib
wxUniversal
wxAdvanced	wxmswuniv28d_adv	wxmswuniv28ud_adv	wxmswuniv28_adv	wxmswuniv28u_adv
wxAUI	wxmswuniv28d_aui	wxmswuniv28ud_aui	wxmswuniv28_aui	wxmswuniv28u_aui
wxCore	wxmswuniv28d_core	wxmswuniv28ud_core	wxmswuniv28_core	wxmswuniv28u_core
wxDbGrid	wxmswuniv28d_dbgrid	wxmswuniv28ud_dbgrid	wxmswuniv28_dbgrid	wxmswuniv28u_dbgrid
wxGL	wxmswuniv28d_gl	wxmswuniv28ud_gl	wxmswuniv28_gl	wxmswuniv28u_gl
wxHTML	wxmswuniv28d_html	wxmswuniv28ud_html	wxmswuniv28_html	wxmswuniv28u_html
wxMedia	wxmswuniv28d_media	wxmswuniv28ud_media	wxmswuniv28_media	wxmswuniv28u_media
wxQA	wxmswuniv28d_qa	wxmswuniv28ud_qa	wxmswuniv28_qa	wxmswuniv28u_qa
wxRichText	wxmswuniv28d_richtext	wxmswuniv28ud_richtext	wxmswuniv28_richtext	wxmswuniv28u_richtext
wxXRC	wxmswuniv28d_xrc	wxmswuniv28ud_xrc	wxmswuniv28_xrc	wxmswuniv28u_xrc

[edit] Building wxWidgets

At this point, you hopefully have a good idea of what configurations you will need to build. If you don't already have either the wx.dsw or wx_dll.dsw (both explained above) workspace open, do so now. The basic process of building wxWidgets involves either batch building all configurations, or changing your active configuration to the ones you need and building those.

If you batch build all configurations, be aware that you will almost certainly run into problems building specific projects in certain configurations. wxWidgets makes every effort to keep these in working order, but there are a lot of different configurations, projects, and distribution methods that can play a part in errors. When projects (or whole configurations) fail to compile you will need to either make sure they are not ones you need, or figure out what's wrong with them and fix them as you go. You should also note that batch building everything will take anywhere from one to two hours (assuming you don't run into problems), and will take up as much as 10GB of disk space.

Building single configurations one at a time will usually take 5 to 10 minutes per configuration, and will result in only needing 400 to 800 megabytes depending on which configurations you need. Using this process can help with pinpointing problems with the build, and you will know for sure when configurations you need failed to build. In theory, this method of building wxWidgets should take more steps, and is slightly more complex, but in practice it tends to be easier since most users run into less problems this way. Skip down to the Building Single Configurations section if you would rather use this method.

If the computer you are compiling wxWidgets on has a multi-core CPU (most newer processors these days), Visual C++ will attempt to build multiple projects simultaneously on each core. This has been known to cause Visual C++ to ignore wxWidgets project dependencies which can result in the failure of some projects to build correctly. If this happens, you can simply just tell Visual C++ to build the solution again until it successfully builds any remaining projects that failed to build. If the number of projects that fail stays the same between two builds, this means that you have a problem involving something else.

[edit] Batch Building All

1. Select "Batch Build..." from the Build menu.
2. Click the "Select All" button to select all projects and configurations (a total of 320 in wxWidgets 2.8).
3. Click "Build" to start building wxWidgets.

Use the time now to go watch a movie (I recommend The Fifth Element), or get a head start reading the wxWidgets Manual. If you come back to find failed builds and are not sure how to fix it, check the troubleshooting section, the FAQs, and lastly, the mailing lists, forums, and IRC. Repeat the steps above until all configurations build successfully. Alternatively, you can figure out which configurations you really need, and use the single configuration build method.

(I have found that if I manually set the Project Dependencies in MSVC before I do any builds, I do not have to repeat the process multiple times. Simply right click on the solution name in the Solution Explorer and select Project Dependencies... from the menu. Then start at the bottom of the list shown below and make each one dependent on the one above it. Once you have done this, simply build as described above and MSVC will build in the correct sequence each and every time. ~BruceKahn)

[edit] Building Single Configurations

Build all libraries you need one by one, in the following order:

    wxjpeg
    wxpng
    wxtiff
    wxzlib
    wxregex
    wxexpat
    base
    net
    odbc
    xml
    core
    gl
    html
    media
    qa
    adv
    dbgrid
    xrc
    aui
    richtext

[edit] Building the wxWidgets Samples

• Open the sample's .DSW file in .NET
• Hit yes to convert
• Select the same build you did above (in 'Steps to build wxWidgets')
• build

However, this may result into rebuilding the wx libs/dlls again. If you had already built these, do following instead:

• Open the sample's .DSW file in .NET
• Hit yes to convert
• remove those projects from the sample solution, which you already have build (in 'Steps to build all wxWidgets projects')
• build

[edit] Creating a New Project by Hand

The main things to worry about with project settings are the C runtime library, preprocessor definitions, additional include directories, libraries that your program needs, libraries that wxWidgets needs, and the disabling of certain default libraries to resolve symbol conflicts that might occur.

Start with a Visual C++ Win32 Project and accept the default settings. (I suggest to check the "empty project" checkbox [or unselect "precompiled header" for static libs] so you can start really clean. Also, don't forget that until you have a .cpp file inside the project, the C/C++ won't appear under "configuration settings" in the project's properties -DL)

[edit] Project Properties

• General
  • Character Set
    • Select Not Set, Unicode, or Multi-Byte depending on what you need.
• C/C++
  • Category: General
    • Additional include directories:
      • Specify the location of the wxWidgets include directory. $(WXWIN)/include
      • Specify the location of the Setup.h file. You need to match it up with the wxWidgets library you are linking with. $(WXWIN)/include/msvc Here's the rundown:

Directory	Basic wxWidgets libraries	Description
lib/vc_lib/msw	wxmsw28_core.lib wxbase28.lib	release ANSI static
lib/vc_lib/mswd	wxmsw28d_core.lib wxbase28d.lib	debug ANSI static
lib/vc_lib/mswu	wxmsw28u_core.lib wxbase28u.lib	release Unicode static
lib/vc_lib/mswud	wxmsw28ud_core.lib wxbase28ud.lib	debug Unicode static

• • • Detect 64-bit Portability Issues: Select No to avoid warning messages on strings.
  • Category: Preprocessor:
    • Preprocessor definitions:
      • Add WINVER=0x0400
      • For projects using GUI components add wxUSE_GUI=1
      • Add __WXDEBUG__ for debug builds that link to wxWidgets debug configurations. Activates wxASSERT(), etc. See the Debugging Overview for more information.
  • Category: Code Generation
    • For the C runtime library, use the Multithreaded DLL for release and Debug Multithreaded DLL for debug builds, as the multithreaded DLL libraries are the ones wxWidgets is linked with by default. If you get something like:

  MSVCRT.lib(MSVCRT.dll) : error LNK2005: _free already defined in LIBC.lib(free.obj) 

then you're linking with the wrong runtime library.

• • Category: Precompiled Headers
    • • See the Tips'n'Tricks section of the wiki for setting up precompiled headers

• Linker:
  • Category: General
    • Additional Library Directories
      • Specify the location of the wxWidgets lib directory. $(WXWIN)/lib/vc_lib
  • Category: Input
    • Add comctl32.lib rpcrt4.lib winmm.lib advapi32.lib wsock32.lib. wxWidgets needs these.
    • Add any of these that you need:
      • Release: wxpng.lib wxzlib.lib wxjpeg.lib wxtiff.lib
      • Debug: wxpngd.lib wxzlibd.lib wxjpegd.lib wxtiffd.lib
    • Add one of the wxWidgets libraries from the table above
      • For example, for debug ANSI static : wxmsw28d_core.lib wxbase28d.lib
  • Category: System
    • SubSystem
      • Set Windows (/SUBSYSTEM:WINDOWS)

[edit] Creating a New Project From a Sample

If you have trouble with the above method, this is also an option. If you can get a sample to build, you should be able to use this method without issues.

This tutorial takes the simple (and usually best) route, of copying a sample's project file. This automatically sets up all the right build configurations, and is less error prone than manually creating a project file.

• First convert samples/internat/internat.dsp to Visual Studio .NET as above. This will create internat.vcproj and internat.sln.
• Copy internat.vcproj and internat.sln to your application directory, rename as myapp.vcproj and myapp.sln.
• Open myapp.vcproj in notepad.
  • Search replace "internat" with "myapp".
  • Search replace "../.." with "c:/wxWidgets-2.6.2" or wherever you installed wxWidgets to.
  • (Note: with wxWidgets 2.6.2 and VC8 Express or VC .NET 2003 (7.1), the above will yield odd results. Try searching and replacing "./../.." with "c:/wxWidgets-2.6.2" or wherever instead. Add more info to this wiki if you find this to be true of other combinations.)
  • Search replace "../.." with "c:/wxWidgets-2.6.2" or wherever you installed wxWidgets to.
  • Save and close.
• Open myapp.sln in notepad.
  • Search replace "internat" with "myapp".
  • Search replace "../.." with "c:/wxWidgets-2.6.2" or wherever you installed wxWidgets to.
  • Save and close.
• Open myapp.sln in Visual Studio .NET, add your source files to the project and build.

Note that you can add the wxWidgets include/lib paths to your Visual Studio's search paths (under Tools>Options>Projects>VC++ Directories). This is recommeded if you will be working with anyone else on the project. Otherwise, specifying your path to wxWidgets directly in the project, as described above, is all you need.

[edit] Visual C++ 2005 Express and Text Editor of Your Choice

If all else fails (although I wish I had tried this earlier), open the sample's converted .vcproj file in a text editor and take a close look at what the paths should be. The solution file is of no value, it will get created automatically. In fact the solution file will be counterproductive if you built all the samples at once, because it brings up all the samples!

In the text editor, pay close attention to the OutputDirectory, IntermediateDirectory, AdditionalIncludeDirectories, AdditionalDependencies, and OutputFile attributes and make sure they are what you expect. Use the $(WXWIN) variable and relative paths whenever possible. You are doing two things at once, preparing your app for building and making sure the project reflects your preferred code organization.

Search and replace the sample name with your app name, then edit it so that it only contains a single Configuration (such as "Release|Win32"). This must match the build under which you compiled wxWidgets. A single configuration may lose some functionality but makes it harder to screw up the file. The uniqueness of the ProjectGUID setting is necessary to calculate the build order correctly from the project dependencies. So you should search and replace the duplicate GUID by a unique one in the .vcproj and .sln files. (Otherwise it should only matter in .NET applications, according to Microsoft.)

Now reopen the .vcproj file in the IDE and remove the bogus files (left over from the sample) and add the real files. If the .cpp files you added do not appear under Source Files, close VC, fire up the text editor again and move the File elements so that they are inside the Filter elements and then close and reopen in VC8.

[edit] Visual C++ 2008 Express & wxWidgets 2.8.6

Herb Thompson's build report, with the steps he followed, looks very useful and up-to-date.

[edit] Troubleshooting

[edit] Problems when using wxALL, SVN or Daily Snapshot Source

Visual C++ will probably complain about "corrupted project files". This is because your project files have Unix line endings (LF) instead of DOS ones (CR LF). You must transform your project files to the DOS format using a program such as Microsoft WordPad or Notepad++. A google search of convert unix dos files should point you in the right direction if you do not already know how to process these files.

If, when building wxWidgets, you get an error like this:

------ Build started: Project: wxregex, Configuration: Debug Win32 ------
Creating ../../lib/vc_lib/mswd/wx/setup.h
The system cannot find the file specified.
Project : error PRJ0019: A tool returned an error code from "Creating ../../lib/vc_lib/mswd/wx/setup.h"
Build log was saved at "file://c:/wxWidgets/build/msw/vc_mswd/wxregex/BuildLog.htm"
wxregex - 1 error(s), 0 warning(s)

Then you will need to copy include/wx/msw/setup0.h to include/wx/msw/setup.h

[edit] Unresolved External Symbol Linker Errors

If you receive unresolved external symbol linker errors such as LNK2001 and LN2019, find a sample wxWidgets application which uses the same functions that are not correctly linked in your application. Load that project into Visual Studio and set the Configuration Properties > Linker > General property page Show Progress attribute to Display All Progress Messages (/VERBOSE). Compile and link the sample application.

When completed, examine the BuildLog.htm produced. Search for the item not linked in your application. The log will show in which library the reference was found. Verify that the cited library is being searched in the build of your application.

[edit] Unresolved Externals for Windows API Functions

If you get unresolved externals to Windows API functions when linking your project, then you may be missing the required Win32 libraries in your project settings. These errors most commonly show for Visual C++ 2005 (8.0) Express users since wxWidgets has relied on the default project configuration to specify the Windows API libraries for linking, and starting with VC8 Express, Microsoft has dropped these libraries from the default configuration since the PSDK containing the libraries is not included in the Express edition.

If you are using Visual C++ 2005 Express Edition and haven't installed the Platform SDK yet, you will need to do so now. First, download the Windows Platform SDK. Next the PSDK's Bin, Lib and Include directories need to be added to your Visual Studio options, or you may get an error message about files such as windows.h not being found. See this Microsoft article for setup instructions.

There are two solutions to this problem. The first is to add the libraries to your global default project configuration where Visual C++ will pick up the settings and apply them to all projects you open that are configured to inherit the settings (this is the default setting for new projects, and all wxWidgets projects do the same). You should try this first if you are using VC8 Express along with the Windows Server 2003 PSDK. The second solution is to manually add the libraries to all projects that need them.

First Solution: Global Library Import Settings

If you are using any other version of Visual C++ other than 2005 (8.0) Express, this should already be setup for you. You can double check your settings though by finding the "CoreWin.vsprops" (found in the "VC/VCProjectDefaults" folder of your Visual C++ installation location) and ensuring that at least the following libraries are listed in your "AdditionalDependencies" setting:

kernel32.lib user32.lib gdi32.lib comdlg32.lib comctl32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib rpcrt4.lib

VC8 Express users need to do this with the "corewin_express.vsprops" file. Slightly more detailed instructions for doing this with the latest PSDK can be found on the Visual C++ Express site.

Second Solution: Manual Import of Libraries

For any project missing these settings, open your Project Properties, select the Linker, under that, select Input settings, find the Additional Dependencies setting and make sure the following are listed:

user32.lib
gdi32.lib
comdlg32.lib
comctl32.lib
advapi32.lib
shell32.lib
ole32.lib
oleaut32.lib
rpcrt4.lib

[edit] MSVC 7.0 (2002) Release Build Problems

There is a bug in VC++ 7.0 (VC.NET 2002) optimisation which causes release builds to work incorrectly. To resolve this, after you have converted the wxWidgets VC6 project file to VC.NET, change the Optimization setting from Maximise Speed (/O2) to Custom. Then change Inline Function Expansion to Disabled. If Disabled is not an option you can add "/Ob0" (without quotes) to the Additional Options of the Command Line. It is thought that this only needs to be done for the wxWidgets library, or other code that implements wxModules. Note that this bug been fixed in VC7.1 (VC.NET 2003).

[edit] MSVC 8.0 (2005) DLL Linker Issues

If you're getting linker errors when trying to build a DLL version of a program, make sure the preprocessor has the WXUSINGDLL symbol defined. If the application crashes immediately after starting or cannot be initialised properly, open the file $(WXWIN)/src/msw/main.cpp and search for and remove the function 'DllMain' then recompile wxWidgets DLLs.

You can also get linker errors when there is mismatch between /Zc:wchar_t setting when the wxWidgets library files were built and the /Zc:wchar_t setting in your project. To change this setting in the Visual Studio development environment:

  1. Open the project's Property Pages dialog box.
  2. Click the C/C++ folder.
  3. Click the Language property page.
  4. Modify the Treat wchar_t as Built-in Type property.

More information about the wchar_t setting can be found in the MSDN documentation: [1]

[edit] MSVC 8.0 (2005) Deprecated Function Warnings

MS has created a bunch of new 'safe' CRT (C RunTime, MS's name for the C Standard Library) and C++ Standard Library routines (with new names). The old 'unsafe' functions have been marked with a DEPRECATED keyword so they will generate a level 1 warnings (the highest level) unless _CRT_SECURE_NO_DEPRECATE (for the C library) and _SCL_SECURE_NO_DEPRECATE (for the C++ Standard Library) are defined or all deprecation warnings are turned off with "#pragma warning(disable : 4996)". Since the new MS functions are not cross platform (and probably never will be) future versions of wx will probably define _CRT_SECURE_NO_DEPRECATE.

In addition, MS has deprecated some of the POSIX-compliant function names in favor of C Standard Library names. Define _CRT_NONSTDC_NO_DEPRECATE to suppress those warnings.

Another solution (to make the warnings go away) for 2.6.0 is to add the following code to your setup.h:

 #if (_MSC_VER >= 1400)       // VC8+
 #pragma warning(disable : 4996)    // Either disable all deprecation warnings,
 // Or just turn off warnings about the newly deprecated CRT functions.
 // #ifndef _CRT_SECURE_NO_DEPRECATE
 // #define _CRT_SECURE_NO_DEPRECATE
 // #endif
 // #ifndef _CRT_NONSTDC_NO_DEPRECATE
 // #define _CRT_NONSTDC_NO_DEPRECATE
 // #endif
 #endif   // VC8+

Adding this to your setup file will solve the problem for the wxWidgets libraries and for your own projects. More information on these changes may be found here and here.

If you want to completely disable the warning in Visual Studio itself, edit the corewin.vsprops file (or the corewin_express.vsprops if you are using Visual Studio Express) in the "C:/Program Files/Microsoft Visual Studio 8/VC/VCProjectDefaults" directory. Add the following tag before the final close tag of the file:

<Tool Name="VCCLCompilerTool" PreprocessorDefinitions="_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE"/>

Note that on some versions (well, Express downloaded in June 2006, anyway) the tool name is "VCCompilerTool". If you use C++ Standard Library classes you may also want to add "_SCL_SECURE_NO_DEPRECATE" to the list.

Also

The deprecations flags can also been defined at the project level by adding them in “Project Property Page / Configuration Properties / C/C++ / Preprocessor / Preprocessor Definitions”.

Note

Defining the deprecations flags at the project level or globally in corewin.vsprops file will not work if the project has been upgraded from a previous version to VC8 (as described above). During the upgrade Visual Studio adds $(NoInherit) to each file level setting, so they do not inherit the project level settings, hence adding the definition on the project level will have no effect. The easiest way to fix this, is to open each project file (.vcproj) in a text editor (Notepad) then do a search and replace on the string ;(NoInherit) and replace it with nothing.

[edit] MSVC 8.0 (2005) Windows XP Manifest Build Problems

MSVC 8.0 has changed the way manifests are embedded in your executable. Your project will not build if you include wx.manifest in your resource file (tested with 2.6.0).

To solve this, exclude the manifest from your resources. In your resource file:

// #define wxUSE_NO_MANIFEST 0	// comment this line out
#define wxUSE_NO_MANIFEST 1	// and add this one

Then add these lines to your one of your source or header files to enable XP-Style common controls:

#if defined(__WXMSW__) && !defined(__WXWINCE__)
#pragma comment(linker, "/"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df'/"")
#endif