setting a breakpoint in a WinForms event handler... and then getting caught in the event loop.

  • Thread starter Thread starter Hazz
  • Start date Start date
H

Hazz

What is the triggering action that raises the event which causes my
breakpoint to be reached, repeatedly, but does not allow my form to ever
remain visible. I set a breakpoint on the line Graphics.. below. Just
curious to help my 'system level' understanding. thx. -hazz

private void InitializeComponent() {
this.Paint += new
System.Windows.Forms.PaintEventHandler(this.Wassup_widdis_Paint); }

static void Main() {
Application.Run(new Wassup_widdis()); }

private void Wassup_widdis_Paint(object sender,
System.Windows.Forms.PaintEventArgs e) {
->Graphics grfx = e.Graphics; }
 
Since the code execution is paused in the paint event there is no way for
the form to paint. Chances are the break point being hit causes your form to
be covered. you can try resizing VS.net and your form so both can be seen
entirely on the screen all at once.

This is the main reason I have two monitors on my work station. The form
goes on one and VS.net on the other when debugging paint routines.

--
Thanks
Wayne Sepega
Jacksonville, Fl


"When a man sits with a pretty girl for an hour, it seems like a minute. But
let him sit on a hot stove for a minute and it's longer than any hour.
That's relativity." - Albert Einstein
 
Hazz,

The Paint event is triggered each time your form is redrawn. If you set
a breakpoint there, control will be given to your debugger. This will
keep your form from ever being redrawn properly.

Regards,
Joakim
 
Thank you for the explanation and the very good tip Wayne. Is there any
special sotware configuration/setting in order to use the two monitors this
way?
Thank you again. -hazz
 
Thank you Joakim. I think I understand that. Events being what they are,
the debugger and display will have to simply play tricks on the developer.
The CPU and the VS tools can only do so much. The two monitor solution
mentioned by Wayne sounds like a real good idea.
 
There's special software you should for a multiple monitor
configuration.

The video drivers will let you move windows from one monitor to the
other (if that's the configuration you choose), which is what you need
for having both the debugger and the app windows visible and maximized.

Regards

Claudio Brotto
 
Really no special software you need, just video cards with drivers that
support multiple monitors. I've been doing multi monitor since 98. Recently
it's gotten much easier to do, as most high end video cards are not dual
head cards. Configuration with them is much more reliable (that you'll get
it working) than having two cards.

With that said you can go with one of the following:

1) 1 agp dual head card
2) 1 Agp card and 1 pci card
3) 2 pci cards

I've had the best luck when doing dual cards using ATI's cards. If you go
the multi card route I would suggest searching on multiple monitors, there
are a few sites out there that allow people to share their experience of
what cards they used an how hard/easy they were to get configured. I
actually screwed up my 98 machine so bad once I had to reinstall, but then
again it was 98.

I would highly suggest getting a dual head card if you are going to do it. I
currently have two Matrox G450's and a ATI 9800Pro all three are dual head
and have served me very well. NVida makes dual head cards as well, though
I've never used one as of yet.

http://search.ebay.com/g450_W0QQfkrZ1QQfromZR8 <-- searched on G450, appears
they go for around $10. Third link in the result, at least for the next
8hrs, is a Quad version of the card. G450 is great for a development
machine, but wouldn't do well with today's games.
 
Thank you Wayne. In addition to the video card/driver considertions, are
there any Visual Studio settings at play here?
Thank you.
-hazz
 
Nothing really that I've run into. You can take any window from one monitor
to another, so I tend to keep VS.net maximized on the primary monitor and my
running application when needed on the secondary monitor.

Wayne
 
Back
Top