views:

132

answers:

5

I'm trying to track down a bug that occurs when I click a particular element on an aspx page...

In the past I've had to track down the class that handles that particular event and put a break point on the line that I think should be hit. Often it takes me several tries before I finally find the correct class....especially if the class is a user control buried somewhere...

So it's left me wondering if there is any way to get Visual Studio to break at the next line of code executed after I click an element (say a button) on an aspx page. I know there is a way to break on any exception that is thrown so I'm thinking maybe there is something similar that could help me.

If this sort of feature isn't a possibility, perhaps someone could suggest a better way for me to quickly find the class I want to debug...

+3  A: 

Are you looking for the Step Into (F11) or Step Over (F10) ?

-- Edit

Do you also know about the Call Stack window? It can help you determine your location, and what is happening.

Noon Silk
sorry, I'm aware of F11, F10, and the call stack window. I'm looking for something that allows me to break once I hit the code base after triggering an action on an aspx page.
mezoid
mezoid: perhaps you want to write `System.Diagnostics.Debugger.Break();` in a specific part of your code? That will force the debugger to break there, regardless of you explicitly setting a break point?
Noon Silk
except that I don't know where the class is that I need to put the break in... :(
mezoid
Yes ... well, I'm afraid there is not much that can help you here, but the application of logic :) (well, maybe this: http://stackoverflow.com/questions/907856/computer-science-undergraduate-project-ideas/1346230#1346230), if Mehrdad accepts it as a project :P)
Noon Silk
ok, well then if there is nothing that does what I'm looking for then I'll have to award you the answer just for telling me it can't be done. :) thanks for your help!
mezoid
You don't have to award anyone an answer. You should only do it if your question is answered. You don't seem to me to have made much effort to try any of the answers given. Which is your choice, I suppose.
Kyralessa
+1  A: 

Debug -> Exceptions

Check thrown for the CLR Exceptions.

EDIT

The odds are you are having a CLR exception. Using this method the debugger will always break when an exception occurs. This is very convenient compared to reading the stack trace.

ChaosPandion
that's good but in my case the bug I'm looking for isn't caused by an exception
mezoid
+1  A: 

Have you tried the Break All ("pause") button? It'll usually break somewhere pretty low on the stack, like at Show() for your main form in a WinForms app, but if you then Step Into to get past that, it'll often work pretty well for this sort of thing.

Kyralessa
I'm not sure the Break All button is quite what I'm looking for as I would think the code would be executed within milliseconds of my click on the screen and as such I wouldn't be able to pause it fast enough.
mezoid
I repeat: Have you *tried* it? You don't try to click Break All after you click the button. You click Break All *before* you click the button, then click Step Into, and *then* click the button.
Kyralessa
Ok, I've tried it again...and it didn't work. Perhaps its because I'm debugging an aspx page. When I hit pause and then click something on the window all it does is try to load the page...but nothing happens...I have to hit run and then pause it again before it will break and by then it is too late. I'll have to try your suggestion one something like a WinForms or Console app and see how it goes for that... if that works I'll mark yours as the answer...but for what I'm after it doesn't seem to work...
mezoid
Ok I've tried it with a simple WinForms app and I figured out what I was doing wrong. When I hit pause it stopped the application and paused on one of the WinForm's default lines of code. I then pressed F11 which then allowed me to access the WinForm. Pressing one of the buttons on the form took me directly to that line of code which is exactly what I wanted. I'll have to try it at Work with the aspx page and see if works there too. I'll try to mark yours as the answer...sorry it's taken me so long to figure out...but I do appreciate having learned something I've been wanting to know for years
mezoid
+1  A: 

Conditional Breakpoints may be your answer. You can set them were you think your code is breaking and they will only halt when the condition is satisfied.

scottm
true, but I'm wanting to find a way to not have to set a whole bunch of break points in order to find the code I'm looking for
mezoid
A: 

Some ideas:

  • If you use a consistent naming convention for your event handlers then it should be trivial to do a global search for them all and add breakpoints. You can quickly record a macro on the first hit and then play back the macro to take all the pain out of repeating the operation many times. With a bit of practice you'll be able to breakpoint all the handlers in a few seconds flat.

  • Add an extra event handler for the event (create it early - e.g. in the constructor - so it's added before all other event handlers that your app adds, and is therefore hopefully called first) and stick a breakpoint in it. Once you've hit the breakpoint you can then single step through the other event handlers on the event.

  • write a custom event handler that handles the click and simply generates a new event. Attach all your other event handlers to this secondary event. Then you can breakpoint the first handler and step through the secondary handlers that it calls.

Jason Williams