Visual Studio 2010: Multiple requests debugging at the same time (Annoying!) - visual-studio

The setup
I have an MVC application that's making AJAX requests into my controller. The javascript is making more than one such request.
On my controller that gets called, I have a break point.
The annoyance
When I want to debug that controller action method, I hit my breakpoint, press F10 to continue on, but then the second request comes in and I hit the breakpoint again! I've now got two requests flowing through my code, and pressing F10 steps between the two, making the debugging nearly impossible as the current line jumps up and down, between files, etc without any consistent flow as it's tracking more than one request in the current debugging session!
My question
Can I tell a single request to just... go away... without affecting the other one? I've tried F5ing just one request, but that makes both continue, not just the current one.

You could disable the breakpoint immediately after its first hit (Ctrl-F9, or right click on the breakpoint and click disable - this is different from removing the breakpoint).
You can also "Freeze" a thread in the threads window (right click on the thread and click "Freeze" - use "Thaw" to reverse this).

Related

IntelliJ : show program run with debugger without stopping on breakpoints?

Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:

How to step back during debugging or back to last breakpoint in Pycharm?

Is it possible that Pycharm 'save' the whole staus at a breakpoint and allow the customer repeat debugging from there?
Occasionally I may need to debug a complicate bug which need ~2 hours to reach the target function. The multi-process code consists of many nested invoking and loops. The narrowing down process is pretty tricky. The first breakpoint is easy to set up. But if the second breakpoint was not set up correctly. Or there was one more clicking on 'step over' button. The debug session may exit since there was error. That is terrible since I may need another two hours to start another debugging. If Pycharm allow me to 'save' the debug status at the first breakpoint and allow me back to there whatever the current session ends or not it will be great helpful.
If I could catch up abnormal result before the session exit, then I need to step back during Pycharm debugging to figure out the issue. I searched and found out that both visual studio and IntelliJ has this ability. 'Jumping to Cursor' in Pycharm looks a similar solution. So far I don't have a chance to verify it by using a complex case.
So in genearal, what is the best strategy to debug those bugs which take long time to reach the starting point but failure point/reason is unclear? Thanks a lot.

How to inspect the flow of events with Firebug (or something like that)?

I'm facing an issue with inputs loosing focus. The issue is like this:
I send an AJAX request to load a form, when loaded I display it with in a modal.
Now if I click on any of the inputs it gains focus and blurs immediately, so I need to click it again (and this time it stays focused).
I need a tool that traces the event flow and dispatching in Firebug's console (or some similar tool), so that I can detect the culprit for this odd behavior and fix it.
I have tried Eventbug and FireQuery; but I haven't be able to find the code that causes this.
You may go to scripts panel of Firebug, then hover your mouse over the input, then click ALTCTRLB from the keyboard to activate "Break on next", then click the input, and it should hit a breakpoint in the onclick handler of the input, then you can go through the code to find potential calls that cause blur (provided that you don't do any aggressive polling via setInterval/setTimeout in your javascript for some reason, or the framework you use doesn't; then it'll likely pause in that code).
You may also want to execute some code at the very beginning of the page to override the addEventListener method so that you hijack it: log any calls to it, and forward execution to the original function; see slides 13-14 of my presentation (I do it in Greasemonkey, but it's not relevant here; just make sure this is executed at the very beginning of the page).

Prevent VS to jump to call return when breaking debug

When you break the debug in Visual Studio (through the Break All menu or the shortcut CTRL+ALT+BREAK by default), it jumps to the line of the call return.
(In my case, using winforms, it jumps to the Application.Run(); line of the Program.cs file).
It's kind of annoying when you're debugging a method and every time you hit Break All, the focus is set back on a file you weren't working on.
Is it possible to disable that jump? I couldn't find any option in the Debugging part of the VS options.
It's not "jumping" - it's breaking to the currently executing line of code. This is the behavior, and is not configurable.
If you want to have it stop at a specific line of code where you're working, you can just set a break point there, instead. This will cause it to break at your breakpoint as soon as it executes the code there.

Intellitrace capture breakpoint events without actually stopping program execution

I like how you can capture breakpoints as Intellitrace events. Breakpoints are easy to add/enable/disable, and can be added/removed at runtime (as opposed to say Console events).
However, of course breakpoints stop the flow of execution, and I have to press F5 F5 F5 F5 F5 F5 constantly while I debug the running application. I'd love to be able to capture breakpoint events in intellitrace and just let the code execute without actually breaking on the breakpoints.
I've also used Console statements as captured intellitrace events, but breakpoints are much easier to add (F9 as opposed to pasting a Console.WriteLine("...") everywhere), and I can add and disable new breakpoints at runtime, whereas if I want to add or remove a Console based event at runtime, I have to stop the program, add/delete, and restart.
Are there any good ways to capture intellitrace events in this way?
I think this is what you are looking for:
http://geekswithblogs.net/sdorman/archive/2009/02/14/visual-studio-2008-debugging-tricks-ndash-advanced-breakpoints.aspx
Basically, you can use an advanced breakpoint to do a number of different things. In your case, you would probably want to use the tracepoint that simply gives a hit count. In other cases, you might want to specify that the breakpoint only occurs after a certain number of hits (maybe you want to be sure a loop isn't infinite).
Visual Studio has a ton of great features inside of the breakpoint option. I'm sure that even if the above option didn't solve your problem that there is still something that is included in the above article that will solve your problem.

Resources