Mr Andersson

Recently I had the opportunity to deal with a couple nasty WM_PAINT handlers. Everyone who have been in a situation where you need to debug some broken paint operations knows that it can be really hard to debug using breakpoints, since you can’t break into the debugger. When you break into the debugger, the WM_PAINT event will trigger once again when you switch back to the program you are debugging. Of course you can overcome this by placing the debugger and the debugee on different areas of your screen, but mostly I don’t think it pays back to use breakpoints for these kind of scenarios.

So what do we do when we have a bug in a WM_PAINT handler? Write a unit test? Nope. At least I don’t, even if that would be my preferred way to go.
As long as I remember I think I have inserted alot of those Debug.WriteLine() statements all around my code, so I can get some kind of trace log for the program.
However, this requires modification and recompilation of the code.

So let me introduce to you something I started using recently: Tracepoints!
I read about them years ago and have tried to use them in earlier versions of Visual Studio. A week ago they became my new little helper… in Visual Studio 2008.

Here is a quick how to from MSDN on how you can use them:
How to: Specify a Tracepoint/Breakpoint Action

So now I don’t use Debug.WriteLine() anymore. Instead, I let a tracepoint print a message including the expression I need to evaluate and print.
However, even though this feature works great, you may run into trouble.
Today I discovered issues where the expression evaluation times out!
The timeout occurred when I had quite a number of tracepoint set in a piece of code I was debugging on my Windows Mobile device.

Every time I have to deal with UI components which implements a quite complex handler for WM_PAINT I always think “There must be some way to test this!”. So far I haven’t found a satisfactory design where UI components meets the requirements of my unit testing framework.
If you have ideas or links on how to succeed with automated testing and UI components, please let me know!

Update: Merrick Chaffer has a quite similar blog post with a nice screen shot on the dialog where you set up your tracepoint

In his preparations on his talk “Reflection 2.0″, Roy writes about a debugger visualizer for the MethodInfo class.
Neat stuff.

…is the name of the blog of a support technician at Microsoft PSS that came to my rescue when we was experiencing hard-to-find memory leaks in a .net->pinvoke scenario in a system at my former client.

I just found her blog (via Johan Lindfors) and it is for sure keeping up with the level of knowledge that I experienced during that support case. This girl is making me feel that debugging crash dumps is piece of a cake.