By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,665 Members | 1,229 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,665 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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

Nov 17 '05 #2

P: n/a
Can you explain more in detail how?

Thanks
Johann

Nov 17 '05 #3

P: n/a
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

Nov 17 '05 #4

P: n/a
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

Nov 17 '05 #5

P: n/a
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


Nov 17 '05 #6

P: n/a
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



Nov 17 '05 #7

P: n/a
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

Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.