Showing posts with label msvs. Show all posts
Showing posts with label msvs. Show all posts

Saturday, August 16, 2014

MSVS Versions Poll Results

Two months ago, I've asked about the oldest version of MSVS you were still using. Without further ado, here are the results of the poll:

I admit to have been (pleasantly) surprised by the number of VC12 users. Of course, this poll, as all web polls, is certainly biased because of the absolutely non-random participants selection, but I still want to believe these results and so we'll probably drop (until enough people object very loudly) VC7 support too soon. VC8 is not much more popular, but there are quite few differences between it and VC9 and we'll still keep supporting the latter one for quite some time, so VC8 can piggyback on its support anyhow.

Thanks to everybody who voted!

Wednesday, August 06, 2014

New MSVS project files

If you try to build the latest wxWidgets sources from Subversion or Git, you may be surprised to discover that the various wx_vcN_*.vcxproj project files don't exist any more. The solution files wx_vcN.sln do still exist (for N from 7 to 12), so if you just use them to build wxWidgets, almost nothing changes for you, but if you use the projects themselves, you will need to use the new ones, without vcN_ part in their name.

Indeed, we now have only one set of projects for VC10, VC11 and VC12 (MSVS 2010, 2012 and 2013 respectively), which is very nice from maintenance point of view and will ensure that all modern, i.e. MSBuild-based, VC projects are always synchronized in the future. It also means that it is a bit easier to customize the projects if you use more than one version of VC at the same time: just copy wx_setup.props file to wx_local.props (this is recommended instead of modifying the former directly as it's under version control and so would appear modified if you do this) and edit this property file. For example, in mine I have


<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <wxShortVersionString>31</wxShortVersionString>
    <wxToolkitPrefix>msw</wxToolkitPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '10.0'">vc100</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '11.0'">vc110</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '12.0'">vc120</wxCompilerPrefix>
    <wxCfg>
    </wxCfg>
    <wxVendor>custom</wxVendor>
  </PropertyGroup>
  ... the rest of wx_setup.props unmodified ...
</Project>

to ensure that different output directories are used for all versions of the compiler. Of course, the other properties can be modified here as well, e.g. you could set vendor to the name of your company if you're distributing custom builds of wxWidgets DLLs.

Other than that, the new projects should work just as well as the old ones, but please let us know if you find any problems with them. Happy building!

Tuesday, August 14, 2012

How to use 2.9.4 wxMSW binaries

We have decided to experiment with providing binaries for wxWidgets releases. So, for the first time ever, 2.9.4 release includes binaries for a few different versions of Microsoft Visual C++ compiler.
However we might not have done a very good job of explaining how to actually use them, the README at the link above is relatively brief and omits some steps, so let me try to explain in more details how to build your wxWidgets applications using the files provided and without building wxWidgets yourself.
First, you need to get the correct files. You will always need the headers one but the rest depends on your compiler version and architecture: as different versions of MSVC compiler are not binary compatible, you should select the files with the correct vc80, vc90 or vc100 suffix depending on whether you use Visual Studio 2005, 2008 or 2010 respectively. You also need to decide whether you use the x64 files for 64-bit development or the ones without this suffix for the still more common 32-bit builds. After determining the combination of suffixes you need, you should download the "Dev" and the "ReleaseDLL" files in addition to the "Headers" one above, e.g. for 32-bit MSVS 2010 development you need wxMSW-2.9.4_vc100_Dev.7z and wxMSW-2.9.4_vc100_ReleaseDLL.7z.

Once you have the files you need, unzip all of them into the same directory, for example c:\wx\2.9.4. You should have only include and lib subdirectories under it, nothing else. To avoid hard-coding this path into your projects, define wxwin environment variable containing it: although it's a little known fact, all versions of MSVC support environment variable expansion in the C++ projects (but not, unfortunately, in the solution files).
Next step is to set up your project to use these files. You need to do the following:
  • In the compiler options, i.e. "C/C++" properties:
    • Add $(wxwin)/include/msvc;$(wxwin)/include to the "Additional Include Directories". Notice that the order is important here, putting the MSVC-specific directory first ensures that you use wx/setup.h automatically linking in wxWidgets libraries.
    • Add WXUSINGDLL and wxMSVC_VERSION_AUTO to the list of defined symbols in "Preprocessor Definitions". The first should be self-explanatory (we only provide DLLs, not static libraries) while the second one is necessary to use the libraries from e.g. lib\vc100_dll directory and not the default lib\vc_dll.
    • Also check that _UNICODE and UNICODE symbols are defined in the same "Preprocessor Definitions" section. This should already be the case for the newly created projects but it might be necessary to add them if you're upgrading an existing one.
      [added at 2013-02-08 in response to comments]
    • Check that you use "Multi-threaded [Debug] DLL" in the "Run-time library" option under "Code Generation" to ensure that your build uses the same CRT version as our binaries.
  • In the linker options you only need to add $(wxwin)\lib\vc100_dll (with the compiler-version-dependent suffix, of course) to "Additional Library Directories" under "Linker\General" in the options. Thanks to the use of MSVC-specific setup.h you don't need to list wxWidgets libraries manually, i.e. you do not need to put anything in the list of "Additional Dependencies".

Now you should be able to build your project successfully, both in "Debug" and "Release" configurations. With MSVC 10 it can also be done from the command line using msbuild.exe. Of course, to run the generated executable you will need to either add the directory containing wxWidgets DLLs to your PATH or copy the DLL files to a directory already on it. Finally, if you want to distribute the binaries created using these options, you will need to install Microsoft Visual C++ run-time DLLs. Again, MSVC 10 has an advantage here as you can simply copy msvcp100.dll and msvcr100.dll as any other DLL, while you need to install specially for the previous compiler versions that use WinSxS ("side-by-side") for them.
Let us know if you run into any problems using these binaries or, on the contrary, if you didn't but were glad to have them. If enough people find them useful, we'll try to provide them again for 2.9.5 and, most importantly, for 3.0.


Updated on 2012-08-23T12:55:10: Corrected linker options instructions.

Tuesday, December 22, 2009

Better display of wxTypes in MSVS debugger

This is a quick note about displaying a few wx types in MSVS (2003 and later) debugger as I just discovered, to some surprise, that some people using wx don't know about it. Let me show what I mean with an example: I have the following in my %VSINSTALLDIR%\Common7\Packages\Debugger\autoexp.dat:

[AutoExpand]
... all the existing stuff ...
; wxWidgets types
wxPoint=<x>,<y>
wxSize=<x>*<y>
wxRect=<x>,<y> <width>*<height>

wxDateTime=<m_time.m_ll>ms
wxLongLong=<m_ll>
wxString=<m_impl>


This allows to see the contents of the variables of the types above in a much better way than the default display (e.g. by default tooltips for wxRects only show x, y and width values but the height is truncated -- hardly convenient). I wonder if others have more types to add to this list?

Of course, there are limits to this approach. For example, I'd really prefer to see an ISO 8601 representation of wxDateTime instead of the number of milliseconds since the Unix Epoch which is currently shown. But this probably requires writing a custom visualizer which is a bit more difficult (would anyone have done this already by chance?).

Still, debugging is much nicer when previewing wxStrings is as simple as hovering a mouse over them so if you don't have the above in your autoexp.dat you should really add it there. Just remember that wxString expansion is for 2.9, if you are using 2.8 you need to use <m_pchData,s> instead.