If I hit F12 while my application runs under Visual Studio in debug mode, the WM_KEYDOWN never reaches my event loop, but it immediately triggers a breakpoint. Is it possible to disable this feature, or reassign it to another, less conflicting hotkey (e.g. CTRL+F12)? I figure the must be a registry key, but I can't find it...
Any help is greatly appreciated!
F12 is a reserved key for the debugger and its kernel-based https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309.aspx
But you can change the registry entry
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug] UserDebuggerHotKey=dword:00000000
to something else like 0x13 (Pause)
got this from http://conemu.github.io/en/GlobalHotKeys.html
You can disable it from Tools->options->Keyboard
It's easy to reassign a value like that to whatever you want.
1) Go to Tools/Options and click on Keyboard (under environment). Then find the command associated with F12. Which one depends on which mapping scheme you use, so I can't tell you the one to find.)
Then change it to whatever you want.
Too bad I can't add comments...
When I type in F12 (for Press shortcut keys), I get Edit.GoToDefinition. If I remove that assignment and then try again, it shows how it is used with Page Inspector.
If you enter F12 and nothing shows, then you can assume that VS is not using F12 and something else is.
You can just try assigning F12 to something and see if that is called instead - then at least you will have some idea of if VS is controlling it or something external to VS is.
Remember that you could also have some application that has remapped F12 so that when you press it, your application is getting a signal that some other key or key combination has been pressed (happened to me once.)
Related
So I have this weird problem where I press keys subconsciously sometimes. F10 (step over) and F11 (step into) are two that I keep pressing... or if I meant to hit F12, sometimes I hit F11 accidently...
Anyway, this is a major annoyance since it starts a build, which takes a while, I immediately start spamming CTRL + BREAK to break the build, but it only rarely works; it seems that it just freezes or maybe there is only a short window of time where it does work? Then if the build succeeds, my configuration is set up to do a deploy as well, and often, VS just locks and I have to end the process with Task Manager and restart VS.
So just wondering if there is any possibility to only allow F10, F11 to work when pressed if I am debugging, where I actually need it (I use attach to process so F5/F10/F11 are useless shortcuts when not debugging)?
Thanks.
You can assign F10 to the following C# command for Visual Commander:
if (DTE.Mode == vsIDEMode.vsIDEModeDebug)
DTE.ExecuteCommand("Debug.StepOver");
It will call StepOver only when you are in the Debug mode. For F11 use Debug.StepInto.
I had the same problem - kept randomly hitting F11 instead of F12. I ended up re-assigning F10 and F11 to something innocuous (like Find Next / Previous) and then re-assigned StepOver / StepInto to Ctrl-' and ctrl-; respectively (these are the same shortcut keys used by the Chrome debugger).
Perhaps a bit extreme, but it works for me. I now have a new problem though where I occasionally invoke Find Next when debugging :) On balance the new problem is less annoying.
I'm using Visual Studio and would like to use the keyboard to go to the previous/next breakpoint. I had a look at Options|Environment|Keyboard but found no such command.
Is there a way to do it?
For people wanting to see each breakpoint, that ended up here. (Like me)
Try Debug -> Windows -> Breakpoints.
You can jump to breakpoints during debugging of application. Here is a list of shortcut keys that might help you.
Create or remove breakpoint on the current line: F9
Execute code one statement at a time, following execution into function calls (Step Into): F11
Execute the next line of code but not follow execution through any function calls (Step Over): F10
Execute the remaining lines of a function in which the current execution point lies (Step Out): SHIFT + F11
Restart a debugging session : CTRL + SHIFT + F5
Resume execution of your code from the current statement to the selected statement (Run to Cursor): CTRL + F10
Run the application (or jump to next breakpoint): F5
Use 'Run To Cursor' (CTRL+F10). The debugger will execute your application up to where your cursor is and break. For more details visit: How to skip over code in the Visual Studio Debugger
If you want to just want to navigate and not use debugger, I use an extension called Bookmarks by Alessandro Fragnani. It's super useful when you have to navigate forward and backwards through long lines of code on a page and even faster if you setup shortcut keys.
Here is how to Configure
I've configured mine shortcut key Manually
When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to
Press any key to continue . . .
thus requiring to activate the window and hit a key. Sometimes this is not appropriate.
Why this matters:
At the very moment I write json serialisation code, my workflow goes like this:
adapt c# code
run a console app that writes file out.json
view out.json in the browser with a json viewer
do this again and again, no need to debug anything, just trimming serialisation and check output is good.
It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps
activate the console window
press key
.
No answers:
Starting the application outside VS in a separate console is not an answer.
Saying, you dont need this.
I'm pretty sure that you cannot affect or change this behavior.
As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.
Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:
%COMSPEC% /k "C:\Path\To\YourApplication.exe"
or
%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"
With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.
Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.
In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.
If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.
If you do need to display output on the console window, you have a couple of options:
Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
I found a solution that works if you are using python (I could not test anything else).
You need to go to
Tools -> Options -> Python Tools -> Debugging
Uncheck Wait for input when process exits normally.
I hope you can apply this somehow to your problem.
2020 UPDATE : Microsoft has listened.
It also closes the console in "Start Without Debugging" mode ;)
The setting is a little buried, but works :
Well, at least in Visual Studio 2010, typing
Console.ReadKey(true);
Removes the "Press any key to continue....."
According to the VS2019 documentation:
Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.
It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.
In vs2017 you have to uncheck the python environment setting under the vs-options:
in german: Auf Eingabe warten, wenn der Prozess normal beendet wird
I have not been able to track down why random actions in Visual studio 2010 will cause the keyboard and/or mouse to start performing different actions than anticipated or more often than not, stop responding to certain actions.
I never loose complete control, but I could return to VS from another screen and any of the following could occur:
Clicking on text with the mouse, acts like I have the shift key down and tries to highlight entire areas
arrow keys will no longer move the cursor
Delete, backspace or enter will stop responding
I am not sure that it is always after returning from running an application/debug, but that is definitely a majority of the times that I encounter the issue. Most of the time I have to completely shutdown VS and restart to get keyboard functionality back. Most of the time, other functions still work such as typing.
I should note, that I always check another application that those keys are responding as they are expected to verify it is only in VS that the problem is occurring.
Any thoughts?
I have occasionally, and for along time, seen "sticky" modifier keys (Ctrl, Alt, Shift) in VS, especially after quitting a debug session. For me it's usually the Ctrl key which turns Shift-F5 (stop debugging) into Ctrl-Shift-F5 (restart debugging). That's a bit frustrating.
The best fix I know is: when you notice this behavior, give each of the modifier keys a press to "un-stick" them, which sounds like what you're doing when you "check another application."
In Visual Studio 2010 (Ultimate), is it possible to step through some code, and, if a variable is not correct (e.g. you want to get all records beginning with 'A' but there is none, so you want to try 'B' instead), is it possible to change the code while in debug mode, to do this (change variables while in debug mode)?
It is quite annoying to have to stop debugging, change a value, then debug again and see the result. It'd be much easier to do it all in debug mode, anyway.
Thanks
In the watch window just enter the statement you want executed. For example if you want to set the variable prefix to "B" then just type prefix = "B" and hit enter.
You may also change code while running, however there are a number of limitations to this feature. See Microsoft's Edit and Continue documentation for details: http://msdn.microsoft.com/en-us/library/bcew296c(v=vs.80).aspx.
In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This works for me.
c