Is there a way to prevent Visual studio to start the debugger when pressing F11? I often press it by mistake when I want to actually press F12.
I do not want to loose the functionality of Step-into which F11 provides but it is annoying when it starts the application.
This is for VS 2010, but it should be similar for others.
In Tools->Options, open Keyboard under Environment. Look up the command Debug.StepInfo. You can remove the default shortcut (F11 (Global)) and then just use the toolbar button to step into, or right click and "Step into specific"--which is what I do since it keeps the debugger from diving into STL functions if they're part of a line of code (as an example).
A hack-around that I use is to use the cancel build command after I accidentally hit F11. The default shortcut is ctrl+pause/break.
This doesn't stop F11 starting a build, but should stop it from running your program.
This is the suggestion on Microsoft's VS Community forum. Currently there is a suggestion from MSFT (I assume official MS dev?) that points to this free extension Tweaks:
Don't start debug on F10/F11 Inspired by the suggestion Please provide
a way to disable F10/F11 until debug mode is entered.
F10 (Step Over) and F11 (Step Into) are two commands people often hit
by accident. That starts a new debugging session and that can be
annoying if you didn't mean for that to happen. They should only take
effect during a debug session.
Install Resharper and Change the Key Short Settings
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.
The question itself is in the title. See screenshots.
When I'm using those both shortcuts, my Visual Studio 2010 does exactly the same action (debug tests). However, the shortcuts are assigned for different buttons.
What am I missing?
UPDATE:
Here is my keyboard customizations in "Tools" - "Customize" - "Keyboard".
There is no difference, VS treats Ctrl+R,Ctrl+D and Ctrl+R,D as the same command. There's ancient history behind this behavior, going all the way back to an old text editor named Wordstar. Which used control key chords like that. Also adopted by Borland, a company that Microsoft was fiercely competitive with. And by me, I still use it, got a weird left pinky to show for it.
You'll have to assign a different chord for the other command.
The difference is that when using CTRL+R, CTRL+D, the test runner runs the tests with the debugger attached.
This means that you can set breakpoints in the tests and step through the code. It is very useful at times.
EDIT: I think I missed the fact that you probably know about the concept of debugging tests. As Fishermaen points out, the shortcuts might be messed up. Do you have Resharper or any other 3rd party tool that alters these settings perhaps?
Check in "Tools" - "Customize" - "Keyboard" if the shortcuts are wired up correctly.
1) I put a breakpoint, VS breaks where I put the breakpoint.
2) I then start browsing around the code normally to put another breakpoint
somewhere down the execution path. (maybe in another class in some other cs file)
3) I would now like to return to where I first stopped (just navigation in the code. Do not confuse with the go back in debugger feature used in VS's intellitrace debugging tool)
Right now I place a bookmark and return to my bookmark. But I forget most of times to place a bookmark. Hence this question. There's got to be a shortcut to get back to current line of execution or stopped at or whatever phrase is used to describe this. I also have Resharper if I can craft up some hotkey or shortcut. Anyway I can get back to where the debugger has "broken". I sometimes also use Ctrl - multiple times to navigate backwards.
thank you
That would be the Visual Studio command "Debug.ShowNextStatement" (usually assigned to Alt+Num*). You can also use the Breakpoints Window (Alt+Ctrl+B) to navigate between your breakpoints.
UPDATE: I implemented #Alex 's request for a more discoverable and accessible MenuItem for this functionality, as part of a commercial Visual Studio extension I created called OzCode. It works similarly to Resharper's Context Actions: when you are in break mode but have navigated far away from the 'current statement', this QuickAction will appear:
I tend to use the call stack window, double click the top line in the stack trace causes the editor window to display the code line where execution halted
This might have very obvious solution but I'm afraid I cannot find out how to disable this specific page which pops up each single time I use the break command whilst debugging. Every time I have to close it because I don't need it; moreover, it pops up any next time I use the break command on the toolbar.
I'm using Visual Basic Express Edition 2010
How can this be disabled?
Thanks.
Just don't use Debug + Break All. It is typically useless anyway because it is pretty unlikely that you'll break your own code. Which is what the window is telling you. Set a breakpoint on a line of your own code, the code you want to debug or verify. Clicking in the left margin will set one.
On one of my two computers I see following behaviour:
Each time I press F10 (Step over) or F11 (Step Into) in the disassembler window, the focus is switched to the source view, resulting in next F10 / F11 done on the source level unless I switch focus back.
Can anyone recommend me what settings to inspect, or what to try to stay in the disassembler view?
Did you try to reset settings on your VS?
from the Visual Studio command prompt window type devenv /ResetSettings
Look in the Tools > Options > Environment > Keyboard section, and check what F10/F11 are currently assigned to (although I can't believe it's something that simple)
Copying the settings from the working computer might solve it. You don't mention what version you're running, but I think they're in the same location in 2005 onwards : My Documents\Visual Studio 2005\Settings\CurrentSettings.vssettings. There's always the Import and Export Settings Wizard too.
Try setting a breakpoint in the assembly view. I'm assuming the existing breakpoints are in the source view.
Could it perhaps be: Tools->Options->Debugging->Enable address-level debugging?
I just tried in VS05, and when I have that unchecked, I can't even bring up the disassembly view, but I would guess that if you somehow got into disassembly view, having that option off would kick you out of disassembly view when you did a step over/into.
Close the source file window ? I had the inverse problem that cause F11 to always debug in assembly, it was fixed by closing the assembly window. May be it works in reverse too ?
Not sure, if this would work but... try if you can?
Open RegEdit
Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a DWORD under this key called TabProcGrowth
Set TabProcGrowth to 0 (zero)
This is what I used when VS2005 debug mode stopped working (0:
Try removing any .pdb files from the directory you are executing from. Also make sure your Options->Debugging->Symbols settings aren't pointing to any pdbs for the files in question.
Of course I'm assuming you've been through all the other Options->Debugging options, including the native section.