How do I write a very simple Visual Studio debugger visualizer?

Question

I'm trying to write an 'autoexp.dat'-based visualizer for a string type. I've scaled-back my ambitions to attempting to write a visualizer for a really simple test type that contains a null-terminated string field:

namespace thizz { namespace izz {
        class MyType {
            const char* _ptr;
        public:
            MyType(const char* ptr) : _ptr(ptr) {}
        };
    }
}

This is my stab at a visualiser, but it has no effect on how Visual Studio (2010) displays an instance of this type:

thizz::izz::MyType
{
 preview ([$e._ptr,s])
}

(That's going at the top of the [Visualizers] section in C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\Common7\\Packages\\Debugger\\autoexp.dat ).

Watching an instance of this type:

thizz::izz::MyType t("testing testing");

Just displays

t | {_ptr=0x0f56a6fc "testing testing" } | thizz::izz::MyType

in the Watch window.

Answer 1

To get an even more versatile viewer try changing to use this:

thizz::izz::MyType {
preview ( #( [$e._ptr,s] ) )
stringview ( #( [$e._ptr,sb] ) )
}

this will also give the magnifying glass icon which will open a larger text view window in the case that you have a longer string. It'll also give you the option of rendering as HTML or XML.

Note that as well as the format of the file being sensitive to whitespace, I've also found that you can't use a colon in the string otherwise it generates parse errors.

The debugger visualisers are incredibly powerful, though the syntax can be quite bewildering. As general advice I would suggest creating some entries first in the [AutoExpand] section to summarise the data types that you are most interested in, and then if you have custom containers then copy and adapt the examples for vector , list , etc, which will give you the largest return for the investment in your time.

Answer 2

I can't give a categorical reason why my original 'code' in autoexp.dat was not working, but I found that the same code worked when all the whitespace was removed.

I then tried re-adding whitespace and found that keeping the initial open brace on the first line was necessary to keep the definition working.