event-level debugger for VB.NET
March 28, 2006 5:28 AM Subscribe
Please suggest a good event-level debugger for VB.NET. I am looking for a debugger which can trap the execution of event handling code , when an event gets triggered from a line of code, by the .NET framework or by some user action.
Events can get triggered from user actions as well as seemingly unthinkable lines of code. Is there a product that can capture the entire event flow ?
Consider a scenario where I change the text of a control in code, which in turn fires the TextChanged event.
When the line of code changing the text of the control is executed, will the debugger immediately jump to the TextChanged event handler ?
Take another example, calling Control.Invalidate internally fires the Paint event for the control. So when the above line gets executed, will the debugger simply jump to the next line in the same function, or is it intelligent enough to jump to the Paint event handler ?
Please suggest a debugger that can fulfil the above needs.
Events can get triggered from user actions as well as seemingly unthinkable lines of code. Is there a product that can capture the entire event flow ?
Consider a scenario where I change the text of a control in code, which in turn fires the TextChanged event.
When the line of code changing the text of the control is executed, will the debugger immediately jump to the TextChanged event handler ?
Take another example, calling Control.Invalidate internally fires the Paint event for the control. So when the above line gets executed, will the debugger simply jump to the next line in the same function, or is it intelligent enough to jump to the Paint event handler ?
Please suggest a debugger that can fulfil the above needs.
Do you have VS.NET 2003 / VS 2005? That is the best .NET debugger around.
If you are looking for a debugger that will automatically step into any event that is being fired, I'm pretty sure there is no debugger that will do that.
To capture when your TextChanged and Paint events are being fired, I would put a Debug.WriteLine() in those events or put a breakpoint on them... I think that's the only way you're going to track when those events are called (while debugging at least).
A good profiler would show you execution sequence, but you wouldn't be debugging, per se. That might be something else you could try. Check out sharptoolbox.com's profiling and debugging section, or AQtime.
posted by blahtsk at 6:19 AM on March 28, 2006
If you are looking for a debugger that will automatically step into any event that is being fired, I'm pretty sure there is no debugger that will do that.
To capture when your TextChanged and Paint events are being fired, I would put a Debug.WriteLine() in those events or put a breakpoint on them... I think that's the only way you're going to track when those events are called (while debugging at least).
A good profiler would show you execution sequence, but you wouldn't be debugging, per se. That might be something else you could try. Check out sharptoolbox.com's profiling and debugging section, or AQtime.
posted by blahtsk at 6:19 AM on March 28, 2006
Response by poster: I have VS.NET 2003.
taumeson, you asked:
I guess the first question I'm getting at is "How is the built-in debugger lacking?"
The answer is what blahtsk said:
"If you are looking for a debugger that will automatically step into any event that is being fired, I'm pretty sure there is no debugger that will do that."
Yes I am looking for that kind of debugger. If I put breakpoints in all the event handlers I have coded, will the debugger jump into action whenever one of those events is fired ? Obviously, the debugger will start stepping into code if the event is triggered by a user action. But what if the event is triggered from an innocuous line of code, or called periodically by the framework ?
Basically the biggest problem I face writing .NET programs is because some events get fired when I dont expect them to. The interplay of code and events is sometimes very complex, which makes it difficult for me to pinpoint the source of the problem.
Moreoever, some events get fired multiple times, when I am expecting them to fire only ONCE. For example, A lot of DataGrid events fire multiple times which is hard to understand. There are a lot of other events which fire multiple times when they should be apparently firing only once.
posted by inquisitive at 6:33 AM on March 28, 2006
taumeson, you asked:
I guess the first question I'm getting at is "How is the built-in debugger lacking?"
The answer is what blahtsk said:
"If you are looking for a debugger that will automatically step into any event that is being fired, I'm pretty sure there is no debugger that will do that."
Yes I am looking for that kind of debugger. If I put breakpoints in all the event handlers I have coded, will the debugger jump into action whenever one of those events is fired ? Obviously, the debugger will start stepping into code if the event is triggered by a user action. But what if the event is triggered from an innocuous line of code, or called periodically by the framework ?
Basically the biggest problem I face writing .NET programs is because some events get fired when I dont expect them to. The interplay of code and events is sometimes very complex, which makes it difficult for me to pinpoint the source of the problem.
Moreoever, some events get fired multiple times, when I am expecting them to fire only ONCE. For example, A lot of DataGrid events fire multiple times which is hard to understand. There are a lot of other events which fire multiple times when they should be apparently firing only once.
posted by inquisitive at 6:33 AM on March 28, 2006
Response by poster: Is this kind of debugger available in VS.NET 2005 ?
posted by inquisitive at 6:35 AM on March 28, 2006
posted by inquisitive at 6:35 AM on March 28, 2006
Yes, if you put breakpoints in each of your event handlers, the debugger will break when they get called under any circumstance. (At least it's supposed to.)
Yeah, TextChanged and DataGrid events can really hose you. In your case I would put Debug.WriteLine() statements in each of your events. Then in the output window you can see a log of what order + frequency your events are really firing in.
VS 2005's debugger is similar to VS.NET 2003's. It has some nice enhancements, but is almost the same.
posted by blahtsk at 6:49 AM on March 28, 2006
Yeah, TextChanged and DataGrid events can really hose you. In your case I would put Debug.WriteLine() statements in each of your events. Then in the output window you can see a log of what order + frequency your events are really firing in.
VS 2005's debugger is similar to VS.NET 2003's. It has some nice enhancements, but is almost the same.
posted by blahtsk at 6:49 AM on March 28, 2006
Have you tried a conditional breakpoint? Maybe you can check for the sender, or output the call stack to Debug.
posted by Psychnic at 10:52 AM on March 28, 2006
posted by Psychnic at 10:52 AM on March 28, 2006
This thread is closed to new comments.
I guess the first question I'm getting at is "How is the built-in debugger lacking?"
posted by taumeson at 6:15 AM on March 28, 2006