A Note about Debugging

 
Chapter 19 - Graphics with GDI+
bySimon Robinsonet al.
Wrox Press 2002
  

We're just about ready to do some more advanced drawing now. First,however, I just want to say a few things about debugging. If you have a go at setting break points in the examples in this chapter you will quickly notice 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 breakpoint in your OnPaint() override simply causes your application to keep painting itself over and over again, so it's 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 in OnPaint() . As expected, the application hits the break point and the debugger comes in, at which point your developer environment MDI window comes to the foreground. If you're anything like me, you probably 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 hit F5 to tell the application to continue, so that you can go on to see what happens when the application displays something else, after it's done 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 gets hit again straight away. If that's what you want fine, but more commonly what you really want is to hit the breakpoint 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 are a couple of ways around 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 never gets 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 .NET.

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 quite 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() for 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() == true)     {     int ii = 0;   // <-- SET BREAKPOINT HERE!!!     }   

This is effectively a quick-and-easy way of putting in a conditional break point.

  


Professional C#. 2nd Edition
Performance Consulting: A Practical Guide for HR and Learning Professionals
ISBN: 1576754359
EAN: 2147483647
Year: 2002
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net