Lit Window Productions

Products
Shop
Knowhow
wxHowto
Intellisense
wxDoxygen
wxSocket
HowTo
Library
About

RSS Feed
What’s this?

Contact
Privacy

Fast, easy dialog editing and code generation with Anthemion’s Dialog Editor for wxWidgets...

BugLister

Small, fast and easy bug tracking system by Lit Window Productions.

Tips & Tricks using Visual Studio .NET

Following are a few tips and neat things to do that will help you developing software with wxWidgets and Microsofts Visual Studio C++.

More Knowhow: Click to read my blog.

wxWidgets is an open source, crossplatform GUI library of high quality. And its completely free, even for commercial use. Click here to read more about wxWidgets...

If you have never heard of wxWidgets before, these tips may still be useful to you.

wxVisualSetup

The easiest way to get these Tips&Tricks

wxVisualSetup includes a Project Wizard, Intellisense, Integrated Help, Dynamic Help and Tips & Tricks. Requires wxWidgets and Visual Studio .NET.


$ 39.95 / € 34.44

Precompiled headers - revisited

The wxWidgets documentation suggest, that you use wx/wxprec.h as the precompiled header file.The way I show here has the following advantages:

  • You can use more than just the wx/wxprec.h header as precompiled header files.
  • You have a place where you can add the neccessary statements for the “debug memory allocation enhancement” (see below).

Follow these steps to set your project to precompiled headers:

  1. Create a header file stdwx.h
  2. Include all headers you want precompiled in this header file. My stdwx.h usually looks like this:
    #include "wx/wxprec.h"               // wxWidgets precompiled / standard headers
    #include "wx/notebook.h"             // other headers I need
    #include "wx/statline.h"
    #include "wx/tglbtn.h"

                 // debug memory allocation enhancement (see next tip)
    #ifdef _DEBUG
    #include <crtdbg.h>
    #define DEBUG_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)
    #else
    #define DEBUG_NEW new
    #endif

    #pragma warning (disable:4786)
    #include <map>
    #include <vector>

    using namespace std;
  3. Create a C++ file stdwx.cpp and add the following statement
    #include “stdwx.h”
  4. Include both, stdwx.h and stdwx.cpp to your project file.
  5. Open the settings for your projects.
  6. Select ‘all configurations’
  7. Select ‘C++ / Precompiled Headers’
  8. Set ‘Use precompiled headerfile (.pch) ... through’ to stdwx.h
  9. Select stdwx.cpp in the list of project files.
  10. Set ‘Create precompiled headerfile (.pch) ... through’ to stdwx.h

That’s it, your done.

Including file and linenumber in the debug memory allocation (memory leak dump)

wxWidgets has debug memory allocation turned on by default, if you use Microsoft Visual C++. If your program has a memory leak, it will dump all leaked memory blocks, when you close the program.

Dumping objects ->
{5641} normal block at 0x00BB30A0, 100 bytes long.
 Data: <               > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
 

This is nice, but you still have to find the exact location where this leak occurs. You can either call _CrtSetBreakAlloc(5641), where 5641 is the allocation index shown in brackets of the allocation dump (see example above).

But there is a much easier way.

  1. Include the following statements in your standard, precompiled headerfile:
    #ifdef _DEBUG
    #include <crtdbg.h>
    #define DEBUG_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)
    #else
    #define DEBUG_NEW new
    #endif
  2. In every CPP file, include these statements immediately after the last #include statement (before the first malloc/new statement):
    #ifdef _DEBUG
    #define new DEBUG_NEW
    #endif

The example above will now print:

Dumping objects ->
P:\SBKService\SBKMainFrame1.cpp(1036) : {5645} normal block at 0x00BB30F0
 Data: <               > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

 

The sourcefile and linenumber where the memory leak occurred are now included and you can double click on the line in the debug output window.

 

Automatically showing wxStrings contents in debug windows

If you are debugging your program, wxString variables show up in the debug windows in the form:
[+] Variable   {...}

You first have to click on the [+] sign to expand the structure. Then you see the m_pchData variable, which is the pointer to the actual data.

I found this to be annoying and looked for a solution. There is a very interesting file called AUTOEXP.DAT, which does exactly what I wanted.

  1. Locate and open a file called AUTOEXP.DAT. Its in the \Program Files\Microsoft Visual Studio\Common\MSDev98\Bin directory, if you are using Version 6. Search for it if you are using .NET Studio.
  2. Add the following line to the [autoexpand] section (or the bottom of the file). With .NET 2003 be careful not to put it in the [hresult] section!:
    wxString=<m_pchData,st>
  3. Restart Visual Studio.

That’s all. Now, when you are debugging and displaying a string, the wxString variable shows up in the form:
[+] Variable   {“Contents of the string”}

This will save you many mouseclicks, especially when you want to watch the changes to this variable. And while you are at it, read the comments in AUTOEXP.DAT. I am sure you can think of more variables you’d like to handle this way.

While you are at it editing autoexp.dat...

 

Preventing the debugger from stepping into trivial functions.

When you are single stepping in the debugger (using F11) and you want to step into a function that has strings as a parameter, the debugger will first step into the string constructor. This is correct but annoying. You don’t want to debug the string constructor. The same applies to many other functions, e.g. new(), malloc(), wxString::c_str(). There is a way to tell the debugger to step over these functions even if you use ‘Step Into’.

Create a ‘NoStepInto’ entry for every function you do not want to step into. Note: Visual Studio uses the regular expression syntax to specify the function names. regexp is much more powerful than wildcards such as ? and *. Search the usenet and read the wx documentation for more information.

Note: Don’t forget - you have to ‘escape’ special characters with ‘\’. If you want to step over wxString::c_str*, you need to write wxString\:\:c_str.* There is a lot of confusion in the newgroups and other examples if you need to write \\:\\: or simply \:\:. My personal view is, \: is enough (as is correct with regexp) and the other expression came from pasting a C string to a newgroup post.

If you are using MS Visual Studio 6, add these lines to autoexp.dat under

    [ExecutionControl]
    wxString\:\:c_str.*=NoStepInto
    operator new=NoStepInto

If you are using Visual Studio .NET 2003 or 2002, modify the registry.

  1. Add the Key NativeDE\StepOver under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1 (or 7.0 if you are using .NET 2002)
  2. For every function you want to skip, add a new key/string value under the StepOver key.
  3. The keys must be numerical. Think of them as linenumbers like in the old Basic days. Due to a bug in the Debugger, these numbers will get evaluated in reverse order.
  4. The string contains the regular expression I have described above.
  5. Example:
    HKCU\Software\Microsoft\VisualStudio\7.1\NativeDE\StepOver\10 = wxString\:\:c_str.*

This will prevent the debugger from stepping into these functions when you press F11 or choose “step into”. Other useful expressions are:

wxString Constructor

wxString\:\:wxString

wxString Destructor

wxString\:\:~wxString

There is a lot more you can do with it. This article in microsoft.public.vsnet.debugging was written by the guy who coded this and it lists the debugger source snippet.

Or search google groups for NoStepInto.

 

Useful links...

More Visual Studio C++ Know How

http://www.highprogrammer.com/alan/windev/visualstudio.html

[Home] [Products] [Shop] [Knowhow] [Library] [About]

© 2004, Hajo Kirchhoff, last modified Mar 06, 2008

email

back to top

webhosting by netissimo