I want to remove several breakpoints along my program execution path. XCode stops at each breakpoint and I want to clear it immediately. In contrast to all other tools that I used to, Xcode does not put cursor on the line it stopped. Therefore, "toggle breakpoint" shortcut instead of clearing current breakpoint, puts breakpoint somewhere out of sight.
To clear current breakpoint I need to grab mouse or press extra shortcut before actually clearing breakpoint. It gets very annoying for several breakpoints in row.
Maybe there's workaround?
You can click inside the topmost thread in the Debug Navigator ⌘+6 to see where you stopped.
If you want to automatically skip a breakpoint or perform other actions when it's triggered you can Right-Click or Control+Click the breakpoint, choose Edit Breakpoint... then check Automatically continue after evaluating actions.
Related
When I have a code file open and a breakpoint hits, Visual Studio automatically switches the open page to the corresponding file and places the cursor on the corresponding line.
This is quite annoying in my present use case where I'm looking at-on screen values and code lines in a shader file simultaneously, using a breakpoint and F5 to jump to the next frame will switch from the shader file to my breakpoint location.
This is not about VS stealing focus, but about preserving internal focus within VS. I just want silent breakpoint hits.
In Visual Studio 2015, you need to right click the breakpoint to choose "Action" option. It will open the Breakpoint Settings dialog. Now you can add the message that you want to write in Output window and check "Continue execution" option. After setting the output message, the breakpoint will not be hit.
In Visual Studio right click on the break point. In the context menu select the When Hit... menu option. On the When Breakpoint Is Hit dialog box check the Continue execution checkbox. Use the Print a message text box to customize a message to be written to the Debug output so you can tell the breakpoint was hit.
Lets say I set a breakpoint with condition, if this break point is hit I want to turn on another breakpoint . Is it possible ?
You can do that manually. If the first breakpoint is hit, the program stops at that breakpoint. Now you can go to Breakpoints Window (Alt-F9) and click on the breakpoint you now want to activate.
Below screenshot has both breakpoints enabled. Click on the checkbox on he left to disable a breakpoint. As an example I have added a condition. To add a condition, right-click on the breakpoint and choose Condition..
As suggested by George, you can have a boolean that is set at the frist breakpoint and use the condition at the 2nd breakpoint to have it break.
I am using Xamarin Studio 5.10.2. In the debugger I can set breakpoints, run, and the debugger does stop at the breakpoints. However, it does not bring the location of the breakpoint into view. I know the breakpoint is hit because it displays the call stack in its window. When I double-click on the top item of the call stack, the source file is opened and the line pending execution is displayed in the center of the editor.
I can step along execution and see the lines highlight as it goes through them, but it never re-centers the current line and it will step right off the bottom of the window. (I can keep it in view by either manually scrolling or double-clicking the top line of the call stack.)
In Visual Studio (with which I'm much more familiar), the pending execution line is displayed automatically when the breakpoint is hit---no need to double-click on the call stack. Is there a way to get this behavior in Xamarin Studio?
Let's say I have 10 breakpoints and I want to clear one but not the other 9.
If I toggle the breakpoint on the one that I want to remove, it is resurrected the next time I restart the app. The only way that I know to permanently get rid of it is to clear ALL the breakpoints, which I would rather not do since I would have to reset the other 9.
Is there a better way in ANY VS version?
The breakpoint's state is only temporarily altered if you change it while you're debugging and it's a multi-bound breakpoint. This is actually a feature of Visual Studio. See the last post here.
If you're not debugging, and you remove it, then it won't come back. Alternately, as others have suggested, you can remove it permanently using the breakpoint management window.
Hitting Ctrl+Alt+B will bring up a list of all breakpoints in your solution, from which you can manually toggle or delete them with a right-click.
Open the breakpoints window (Debug -> Windows -> Breakpoints), select the breakpoint you want to delete and press the delete key (or click the cross icon).
If you are toggling the breakpoint using the keyboard (F9 using my keyboard mappings), it sometimes doesn't remove it properly. Pressing F9 again will remove it fully (this is due to the breakpoint being set on multiple threads and toggling it whilst debugging only disables the main breakpoint but not the ones for the other threads).
If you want to delete a breakpoint with F9 or by clicking the red glyph, that breakpoint needs to be childless. Otherwise, the breakpoint will persist through its surviving child breakpoints. (Child breakpoints can form when you set breakpoints during debug.)
You could check this question, " Disable/remove child Breakpoints? ", for a macro to remove child breakpoints. I think you shouldn't call the macro during a Debug session though, as this might result in your breakpoints to not be hit.
The following code can be used as a macro to remove the breakpoint on the currently selected line. (Note that Visual Studio automatically selects the line of a breakpoint when it is hit.)
Sub RemoveBreakPoint()
Dim debugger As EnvDTE.Debugger = DTE.Debugger
Dim children As EnvDTE.Breakpoints
Dim sel As Integer = DTE.ActiveDocument.Selection.ActivePoint.Line
For Each bp As EnvDTE.Breakpoint In debugger.Breakpoints
If bp.File <> DTE.ActiveDocument.FullName Then
Continue For
End If
For Each bpc As EnvDTE.Breakpoint In bp.Children
If bpc.FileLine = sel Then
bp.Delete()
Exit For
End If
Next
Next
End Sub
You can assign a keyboard shortcut to it for easy access. (Tools > Options > Environment > Keyboard.)
Cross-post from https://stackoverflow.com/a/35935390/257470 , but it's even more relevant here.
There are some answers here, but in my opinion proposed actions are distractive to use during debugging (I don't want to lose my focus).
My flow with sticky breakpoints during breakpoints is as follows:
During debug, DISABLE the breakpoint instead of removing it.
Possible ways of disabling a breakpoint:
hover with cursor and click the two cycle icon;
or use context menu on it;
or keyboard short-cut CTRL+F9.
Later on, during development, I remove a disabled breakpoint when I see one.
PS. It's also a good practice to remove all breakpoints once in a while.
Often, when I have a breakpoint on some line in Visual Studio, The program will run and stop there. great. I will then click the red circle (or press F9) to remove it. Obviously I don't want my program to keep stopping there. The problem is that the next time I refresh the page the breakpoint is back! The only way to permanently remove it is to open the breakpoints window and remove it there. Why does this happen and how can I change this behavior?
I have noticed that these breakpoints which keep coming back have a little plus next to them in the breakpoints window which when you click on - open up many sub lines of breakpoints. What is the deal with that?
Thanks,
Adin
Helpful Key combo: to permanently delete all breakpoints, press CTRL + SHIFT + F9.
Just clear the breakpoint while the debugger is off. When you clear or add a breakpoint while debugging, the action only lasts for that debugging session.
The plus in the breakpoints window is there when one user-supplied breakpoint binds in multiple places. This can happen when a single file is loaded multiple times in the same debugging session, for example. The + lets you look at each of the places it bound.
#Joel: modifying breakpoints during a debugging session does not make your change temporary, although there are circumstances (like the original question), where the actual behavior can be non-obvious.
I've post suggestion to MS to fix it:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391642
It appears since Visual Studio allows multiple breakpoints on a single line, i.e. in separate sub-clauses, architecturally it allows multiple identical breakpoints. The interface does not necessarily reflect this and you will see the removal of a breakpoint as graphically removing it, but not programmatically removing all instances of it.
Looking at the Debug > Windows > Breakpoints window shows for a given set of breakpoints on a line, they are stored in a sub-tree under that line item. Removing a breakpoint while watching this list will reveal the behaviour, that only one of a series of identical breakpoints is removed from the list associated with that line. By removing the breakpoint line item and with it all sub items it will completely remove all instances of the breakpoint.
Wipe the breakpoint out using the Breakpoints Window (Ctrl + Alt + B).
While debugging, when you hit the breakpoint, look at the BreakPoint window for the one that is bold.
Then, right-click it and choose Delete.