Suggestion on how MS can improve debugging with "automatic breakpoints"

[Johann Blake]

It would be nice to have Visual Studio .NET automatically break into
the code whenever an event is generated without having to explicity set
a breakpoint. It often happens that when a piece of code is executed,
it automatically forces events somewhere else in code to be raised.
Sometimes these events are generated by the source code written by the
developer and sometimes they are done by controls or other
behind-the-scenes code that was not written by the developer. Because
no breakpoint may exist in an event, the programmer may not even know
that the event was raised and the code within this event may do
something that could explain reasons why something is happening or not
happening. A feature should be added to VS that allows the programmer
to cause the IDE to stop on the first line in any event whenever the
event is fired. This shouldn't be too difficult to implement since it
is internally known what is an event and what isn't. In addition, it
should be possible to exclude certain events from being caught. If a
timer event were being used, it would constantly trigger and this may
not be of any interest to the programmer. This automatic breakpoint
feature in events is one that all programmers would love.

Johann Blake

[Ollie Riches]

you could write a macro to do it....

"Johann Blake" <jo*********@gmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...

It would be nice to have Visual Studio .NET automatically break into
the code whenever an event is generated without having to explicity set
a breakpoint. It often happens that when a piece of code is executed,
it automatically forces events somewhere else in code to be raised.
Sometimes these events are generated by the source code written by the
developer and sometimes they are done by controls or other
behind-the-scenes code that was not written by the developer. Because
no breakpoint may exist in an event, the programmer may not even know
that the event was raised and the code within this event may do
something that could explain reasons why something is happening or not
happening. A feature should be added to VS that allows the programmer
to cause the IDE to stop on the first line in any event whenever the
event is fired. This shouldn't be too difficult to implement since it
is internally known what is an event and what isn't. In addition, it
should be possible to exclude certain events from being caught. If a
timer event were being used, it would constantly trigger and this may
not be of any interest to the programmer. This automatic breakpoint
feature in events is one that all programmers would love.

Johann Blake

[Johann Blake]

Can you explain more in detail how?

Thanks
Johann

[Ollie Riches]

you want a break point added in every event handler in any code you have
written for a solution\project open in VS.Net.

therefore just create a script or macro to loop through all the classes in a
project and examine any object instant for any event handlers and then go to
all the event handlers and insert breakpoints as required - simple :)

personally I think you are better of just using a
System.Diagnostics.Debugger.Break() call but that isn't going to suit
everyone.

HTH

Ollie Riches
"Johann Blake" <jo*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Can you explain more in detail how?

Thanks
Johann

[Lebesgue]

Your solution wouldn't work since the suggestion is to break on all event
handlers, not just in your own code.

"Ollie Riches" <ol**********@phoneanalyser.net> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl...

you want a break point added in every event handler in any code you have
written for a solution\project open in VS.Net.

therefore just create a script or macro to loop through all the classes in a project and examine any object instant for any event handlers and then go to all the event handlers and insert breakpoints as required - simple :)

personally I think you are better of just using a
System.Diagnostics.Debugger.Break() call but that isn't going to suit
everyone.

HTH

Ollie Riches

[Ollie Riches]

I realise that, why would you want to break on an event handler for which
you don't have any debug information.

"Lebesgue" <no****@spam.jp> wrote in message
news:eW*************@TK2MSFTNGP11.phx.gbl...

Your solution wouldn't work since the suggestion is to break on all event
handlers, not just in your own code.

"Ollie Riches" <ol**********@phoneanalyser.net> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl...

you want a break point added in every event handler in any code you have
written for a solution\project open in VS.Net.

therefore just create a script or macro to loop through all the classes
in

a

project and examine any object instant for any event handlers and then go

to

all the event handlers and insert breakpoints as required - simple :)

personally I think you are better of just using a
System.Diagnostics.Debugger.Break() call but that isn't going to suit
everyone.

HTH

Ollie Riches

[Lebesgue]

That's true, maybe this is the thing Johann is missing. But you could still
break on event handlers in your own referenced assemblies (for which you may
have debug information (and still don't have source code so macros wouldn't
help)).

"Ollie Riches" <ol**********@phoneanalyser.net> wrote in message
news:uR**************@TK2MSFTNGP12.phx.gbl...

I realise that, why would you want to break on an event handler for which
you don't have any debug information.

"Lebesgue" <no****@spam.jp> wrote in message
news:eW*************@TK2MSFTNGP11.phx.gbl...

Your solution wouldn't work since the suggestion is to break on all event handlers, not just in your own code.

"Ollie Riches" <ol**********@phoneanalyser.net> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl...

you want a break point added in every event handler in any code you have written for a solution\project open in VS.Net.

therefore just create a script or macro to loop through all the classes
in

a

project and examine any object instant for any event handlers and then

go to

all the event handlers and insert breakpoints as required - simple :)

personally I think you are better of just using a
System.Diagnostics.Debugger.Break() call but that isn't going to suit
everyone.

HTH

Ollie Riches

[Lebesgue]

There will be a chat concerning VS Debugger tomorrow, maybe you could join
and see what would the Visual Studio Debugger team think of your suggestion

http://msdn.microsoft.com/chats/#05_0908_MSDN_VSD

"Johann Blake" <jo*********@gmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...

It would be nice to have Visual Studio .NET automatically break into
the code whenever an event is generated without having to explicity set
a breakpoint. It often happens that when a piece of code is executed,
it automatically forces events somewhere else in code to be raised.
Sometimes these events are generated by the source code written by the
developer and sometimes they are done by controls or other
behind-the-scenes code that was not written by the developer. Because
no breakpoint may exist in an event, the programmer may not even know
that the event was raised and the code within this event may do
something that could explain reasons why something is happening or not
happening. A feature should be added to VS that allows the programmer
to cause the IDE to stop on the first line in any event whenever the
event is fired. This shouldn't be too difficult to implement since it
is internally known what is an event and what isn't. In addition, it
should be possible to exclude certain events from being caught. If a
timer event were being used, it would constantly trigger and this may
not be of any interest to the programmer. This automatic breakpoint
feature in events is one that all programmers would love.

Johann Blake