Is there a shortcut to cycle through my breakpoints? I often lose track of the breakpoints when debugging a project. When I finish working with one bug, I have to reset my breakpoints for a new bug that I am about to solve. It would be handy to have a keystroke that would allow me to cycle through the breakpoints and disable ones I don't need and keep the ones I need.
You can always open the breakpoints window (Ctrl + Alt + B) to cycle through them.
I don't believe you can.
You can display a list of all breakpoints and jump to them using the breakpoint view (Debug / Windows / Breakpoints).
You may also be able to write a macro to do it if you want.
I don't think there is a built in way of doing this. However you might want to take a look at this question. You can probably save the breakpoints for one bug and load it whenever you want it.
Related
Regular Visual studio has this nice feature. I don't think it is available in VS Code.
When a breakpoint hits you can jump right to bebugging (pressing f5,f10 etc) without having to click on the IDE first. I love this feature. Does anyone know if VS Code supports this as well?
I think it is supposed to focus the vscode window. There is this setting:
Debug : Focus Window on Break
which is enabled by default. But see https://github.com/microsoft/vscode/issues/80441 and https://github.com/microsoft/vscode/pull/77213 it looks there are issues.
It doesn't work for me either on Win10. I added my example to https://github.com/microsoft/vscode/issues/105913. You may want to do the same.
I often find myself in a situation where I wish to break on several breakpoints in a run, but only for a while until I have seen enough on on those breakpoints and would like the Visual Studio to stop breaking on the breakpoints for the remainder of the current debug session.
I certainly do not want to delete all breakpoints because later I may change something in database or the code, and would like to perform a new, similar run to the one described above again.
I do not want to disable all breakpoints, since I want them to be activated again at the next debug run. At the same time I already have breakpoints, both active and disabled, in other parts of the code (which I am not currently interested in for instance) but I do not want to disable them and then try to remember later which I need for debugging a specific area/functionality of the code.
What I want is simply to be able to tell Visual Studio that "from now on as I resume execution, please ignore all breakpoints for the remainder of this debugging session. Thank you very much!"
So for the next debug run, all breakpoints should be hit again as they already were configured before as usual, but I mean at some point when I have seen enough I just want to continue execution without breaking. and without changing the status to "disabled" for all breakpoints - because doing so will make them stay disabled even at the next run, and I do not want to "Enable all" because I already had some breakpoints on my list which were disabled. And I certainly do not want to manually select/deselect breakpoints before every run just because I chose "Disable all" during a run.
Is this possible to and, in that case, how to do it?
Thanks!
I'm using VS2017 but hopefully the options are similar in VS2013:
Go to the Debug menu, then Windows > Breakpoints to open the Breakpoints window.
From here, the blue curvy arrows in the toolbar allow you to Export and Import breakpoints into an XML file.
So you could export all of your breakpoints, then delete them all. Later you can re-import them instead of having to set them all up again manually.
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.
I still have to use the VB6 IDE.
Unfortunately every time I start the IDE one of the buttons of the toolbar disappears. Almost always it's the Run button which goes first. Sometimes also items from the menu bar or the context menus are missing.
I have to reset the toolbars almost every time I start the IDE (Which is quite often during a typical work day). Recently I bought an IDE plugin which modifies the menu bar and requires a restart after every reset of the menu bar. (Otherwise it would crash)
I could live with just the resetting, but the restart is really annoying.
Is there something I can do?
To solve this problem:
Unload all add-ins.
Right-click on a toolbar and select the Customize... menu.
For each toolbar click the Reset... button (6 times in total).
Reload the add-ins.
For me action 3 was enough.
cf. MZTools faq (thanks to Andrea Bonafini), but these steps are originally from MSDN
It sounds like you recently bought a bad add-in. Can you get your money back? Every time I've had problems with disappearing controls in the IDE it has been due to a bad add-in. You can find out which one it is by disabling them, one by one, each time using the IDE for a while, then re-enable it and disable the next one, until the problem stops.
I still use one problematic add-in. It exhibits behavior similar to yours in that it makes the run button disappear. I avoid the problem by only loading the add-in when I need it, use it (it formats code), then I immediately unload it. If you don't use the functionality of the add-in that often, this could be an acceptable workaround.
Yea, i have this same problem with one of the add-in. But if you reset it. Shut the IDE down and open it back up again without doing anything, the IDE shouuld be able to retain the previous clean setup.
It's just guest, but:
Each graphical element on IDE (like button) is kind of resource (i.e. GDI handle).
Maybe your VB app doesn't manage these resources good enough and after sometime VB IDE cannot redraw elements like buttons (run is used often).
Also, maybe some IDE add-in is in conflict with some other add-in/application and breaks something -- I have this problem with Clip-X and MZ-Tools.
I had a similar problem when I was setting up the IDE to use for the first time, though it may not be helpful if you've been using the same IDE for a while. When I first started using the IDE, I would modify the toolbars and then close the IDE. When prompted if I wanted to save the open file I always said No, since the file was just a dummy file I was using to open the IDE with. Turns out the IDE was saving the toolbar preferences with that file, so they never got saved.
Try opening a file, customizing the UI, saving the file, then closing without modifying the code. This was the solution for me.
I've tracked down the problem and as suggested it was an add-in.
The problem went away as soon as I disabled the Visual Basic 6 Resource Editor.
How to restore your VB6 IDE without reinstalling:
Run Regedit
Find the entry for Visual Basic 6.0
Export your settings in case things
go wrong
Delete the 'UI' setting
Run VB and you will have your popup
menus back
The 'Find' button disappeared from my VB6 toolbar forcing me to select the Edit menu to use Find. I had two add-ins enabled: vbCodePrint and ResourceEditor; so I did away with both of them, turned VB6 off and back on, then put both add-ins back in and my button returned.
If you're still using the VB6 IDE, and I do amongst others, then this problem is not likely to have gone away. I use VB6 in Windows 10, and the problem is still there. But it doesn't affect me anymore.
I have had this problem a few years into using VB5 and VB6. Today, if I start VB6 directly, it may work fine the first time, but buttons will go missing the second time -- ALWAYS.
My solution, which I developed from day one:
Do whatever needs to be done to restore all your buttons. Save the Visual Basic 6.0 registry settings to a file, as suggested previously, and only keep the UI entry. Sometimes, you have to exit VB6 for it to post changes to the registry. So if this doesn't work the first time, try exiting before saving the settings.
I use my own program to launch VB6, which automatically copies my VB6 registry backup back into the registry -- by calling "RegEdit.exe /S D:\VB\IDE_Fix.reg" -- before I launch the IDE . This works every single time, and requires no action on my part.
If you read this, that means you are a programmer. You can make this work by yourself.
Mike
Reinstall,clean registry and update with SPacks etc....