Debuggin a form in VS.NET

  • Thread starter Thread starter John Bailo
  • Start date Start date
J

John Bailo

I am trying to debug a form in VS.NET 2003

I set some breakpoints for a treeview click event.

This is what happens:

The form loads.
I click a node in treeview
The break point is hit

At this point, the form is frozen...I cannot minimize it and it blocks
my access to the studio IDE so I can't:

a) press the step through button
b) see what the code is

I have to press F5, shut down and make sure the form is not blocking the
screen.

Why does the form lock up during debug? That's kind of useless IMHO.
 
My experience of WinForms development in VS2003 is that when the breakpoint
is hit, the application stops being refreshed / listening to messages, but
either the VS IDE comes forward so I can debug, or I can click on it in the
task bar to make it come forward.

Is this problem specific to breakpoints in event handlers of a treeview, or
is it a more general problem?

--Bob
 
Bob said:
My experience of WinForms development in VS2003 is that when the breakpoint
is hit, the application stops being refreshed / listening to messages, but
either the VS IDE comes forward so I can debug, or I can click on it in the
task bar to make it come forward.

Is this problem specific to breakpoints in event handlers of a treeview, or
is it a more general problem?
Click to expand...

I am populating a TreeView control with and XmlDocument that is returned
from a web method.

I am debugging the translation from Xml into the treeview...if I set a
breakpoint in there ( which is triggered by pressing a form button )
that is where the form becomes immobilized.

I can work around it by moving the form to the side of the screen -- I'm
just wondering why it gets frozen there.
 
I would guess it's because the debugger is blocking the UI thread somewhow,
but I really don't know.

I'm not sure I care for the way the whole UI "whites out" a few seconds
after a breakpoint, either; it would be nice at times to refer to what has
happened so far in the UI, but you can't, even if it's *not* in the way.
It's just a limitation of the architecture I guess.

--Bob
 
Bob said:
I would guess it's because the debugger is blocking the UI thread somewhow,
but I really don't know.

I'm not sure I care for the way the whole UI "whites out" a few seconds
after a breakpoint, either; it would be nice at times to refer to what has
happened so far in the UI, but you can't, even if it's *not* in the way.
It's just a limitation of the architecture I guess.
Click to expand...

Ideally I would have two monitors, or just virtual desktops ( which XP,
unlike linux, doesn't support)

One running the IDE.

One running the app as the user would see it.
 
Back
Top