A Note About Debugging C# Help

You are just about ready to do some more advanced types of drawing now. First, however, we just want to say a few things about debugging, If you have tried setting break points, then you have noticed that debugging drawing routines is not quite as simple as debugging other parts of your program because entering and leaving the debugger often causes Paint messages to be sent to your application, As a result, setting a break point in your On Paint () override can simply cause your application to keep painting itself over and over again, so it is 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 On Paint () 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 that 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 discover 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 is 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 have selected some menu option to read in a file or in some other way changed what gets displayed. It looks like you are stuck, Either you do not have a break point in On Paint () at all, or your application can never get beyond the point where it is displaying its initial startup window.

There is a workaround to this problem.

With a big screen, the easiest way is simply to keep your developer environment window tiled rather than maximized. Also, you want to keep it well away from your application window, so that 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 (you can also get a second moniter). 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:

Being a Top Most 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 On Paint () 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. Then place the break point inside the if block, like this: