A Note about Debugging

You’re just about ready to do some more advanced types of drawing now. First, however, I just want to say a few things about debugging. If you have tried setting break points in the examples of this chapter, you will have noticed that debugging drawing routines isn’t quite as simple as debugging other parts of your program. This is because entering and leaving the debugger often causes Paint messages to be sent to your application. The result can be that setting a break point in your OnPaint() override simply causes your application to keep painting itself over and over again, so it’s basically unable to do anything else.

A typical scenario is as follows. You want to find out why your application is displaying something incorrectly, so you set a break point within the OnPaint() event. As expected, the application hits your break point and the debugger comes in, at which point your developer environment MDI window comes to the foreground. You more than likely have the developer environments set to full-screen display so you can more easily view all the debugging information, which means it always completely hides the application you are debugging.

Moving on, you examine the values of some variables and hopefully find out something useful. Then you press F5 to tell the application to continue, so that you can go on to see what happens when the application displays something else after some processing. Unfortunately, the first thing that happens is that the application comes to the foreground and Windows efficiently detects that the form is visible again and promptly sends it a Paint event. This means, of course, that your break point is hit again. If that’s what you want, fine. More commonly, what you really want is to hit the break point later, when the application is drawing something more interesting, perhaps after you’ve selected some menu option to read in a file or in some other way changed what gets displayed. It looks like you’re stuck. Either you don’t have a break point in OnPaint() at all, or your application can never get beyond the point where it’s displaying its initial startup window.

There is a workaround to this problem.

If you have a big screen the easiest way is simply to keep your developer environment window tiled rather than maximized and keep it well away from your application window, so your application is never hidden in the first place. Unfortunately, in most cases that is not a practical solution, because that would make your developer environment window too small. An alternative that uses the same principle is to have your application declare itself as the topmost application while you are debugging. You do this by setting a property in the Form class, TopMost, which you can easily do in the InitializeComponent() method:

 private void InitializeComponent() {    this.TopMost = true; 

You can also set this property through the properties window in Visual Studio 2005.

Being a TopMost window means your application can never be hidden by other windows (except other topmost windows). It always remains above other windows even when another application has the focus. This is how the Task Manager behaves.

Even with this technique you have to be careful, because you can never be certain when Windows might decide for some reason to raise a Paint event. If you really want to trap some problem that occurs in OnPaint() in some specific circumstance (for example, the application draws something after you select a certain menu option, and something goes wrong at that point), then the best way to do this is to place some dummy code in OnPaint() that tests some condition, which will only be true in the specified circumstances - and then place the break point inside the if block, like this:

 protected override void OnPaint( PaintEventArgs e ) {    // Condition() evaluates to true when we want to break    if (Condition())    {       int ii = 0;   // <-- SET BREAKPOINT HERE!!!    } 

This is a quick-and-easy way of setting a conditional break point.