Win32: Debugging Controls
Here's a problem I've run into a few times, and a couple of solutions. Not rocket science, but these are things that took me a while to figure out, so maybe you'll find them useful.
Here's the scenario: You've got a Windows application that's doing something wrong in rendering a control, or in processing a message the control generates. You need to find the code that's responsible for that control.
Sometimes, especially in a large application or a slightly older one, it's not easy. Maybe the custom control is implemented in a DLL; maybe there are a number of libraries of controls and you don't know where this one came from.
There are two ways you can find it's source (assuming you have it). First, use Spy++ (which comes with Visual Studio) to find the control in question (using the Find Window button on the toolbar, and dragging the little target onto the window), and look at the Control ID in it's properties.
This number is associated with the control. Lets say the Control ID is 00000403 - this is in hex, which is 1027 decimal. Search the header files for 1027. That might find you a hit, or it might not - if the number is derived (ie, WM_USER+3), then you won't easily find it that way. Often, however, this lets you find a symbol to associate with the control, and you can search your source for that symbol.
If that doesn't work, a very handy trick is setting a breakpoint on the window proc of the control (if you're trying to find code for a custom control), or it's parent. To do this, use Spy++ again to find the control, and get the Window Proc value. Now in Visual Studio, insert a breakpoint at that address (put 0x in front of it, it's a hex address). It's easy enough to do - on the Insert Breakpoint dialog enter the Window Proc value as the Function you want to break.
Now run your app and interact with the control, and you should pop into the debugger. If you set the breakpoint in the parent's WndProc, then you might have some filtering to do to figure out which messages are notifications from the child, but you're probably not far off.
Yes, I'm back to being a C++ Win32 guy.