Sorry this is a really stupid question:
I'm recording a video of something I'm working on in visual studio and I was wondering if there are any 'safe' (by default not used) hotkeys to use for recording start / stop.
I've always used f10, but that's build/run for VisualStudio.
Alternatively... is it simpler / advisable to just change the VS hotkey or disable it all together? (I don't mind clicking the little button).
Is there any 'professional' philosophy or best practices when it comes to hotkey conflicts?
Thanks.
You can view/search/rebind Visual Studio hotkeys in menu:Tools - Options - Environment - Keyboard.
If you want a hotkey that is definitely not being listened to by any software, on Windows any keyboard buttons (such as less-commonly-used Right Alt, Scroll Lock, media buttons on some keyboards, etc.) can be rebound to F13..F24 using registry or software (such as SharpKeys)
Related
I recently started using Visual Studio, and for the most part it is fine. However, I have noticed that there are some hotkey bindings while debugging associated with the mouse 4/5 buttons. I use those buttons for push to talk on my voip software. As a result, whenever I go into debug mode I can no longer talk to my coworkers.
I would very much prefer to not have to change my p2t button as it is very ingrained into my workflow at this point.
It seems that the mouse buttons are not available for rebinding via Tools -> Options -> Environment -> Keyboard
Does anyone know of a solution for this? I saw something similar in this topic, but it is about assigning extra hotkeys and doesn't seem related to my issues.
Can I use the buttons on a gaming mouse for visual studio shortcuts?
For example, I want to configure them for build, rebuild, copy, paste, etc.
To be specific I am about to buy a Logitech G600 mouse.
Yes not only can it be done, but you can do it for other IDEs too.
If you work on multiple IDEs, it can be a confusing sometimes when you switch back and forth between the two.
The G600 is great if you set up a generic button template that mirrors your workflorw.
That way even if you switch between languages/IDE your workflow (i.e. button/command locations) remains unchanged.
I have posted in detail here if you're interested to find out more.
https://processwire.com/talk/topic/345-need-a-new-mouse/?page=2&tab=comments#comment-165396
It can be time-consuming to set up all the shortcuts, so if anyone reading this that is interested they can ping me for my profile(s) to take home and edit for use.
I thinkt that this is doable, If you can simulate keystrokes for the buttons. Check the software that Logitech supplied with your mouse to do this.
I see that in Tools -> Options -> Keyboard you can set Keyboard shortcuts for a large number of tasks. I tried searching for "Close" and these are the results, amongst a few others:
File.Close
File.CloseAllButThis
File.CloseProject
File.CloseSolution
If I set File.Close to be Ctrl+W (Honestly, why doesn't Microsoft innately support such a universal shortcut is beyond me) it mostly works, however if I have both the code-behind and the Designer view open for a form, it closes both tabs. Should I be setting a different command, or am I stuck with this? It's a small inconvenience, but it really irritates me.
I don't know if it's the same in VS2010, but in VS2012 this command is called "Window.CloseDocumentWindow" and it is mapped to Ctrl+F4 by default, to mirror Alt+F4 for closing application-level windows.
I believe the Ctrl+W shortcut was first brought to Microsoft Windows by Adobe Photoshop, a carry-over from Apple OS X, where Adobe seems to have remapped all of the ⌘ command+* shortcuts to Ctrl+*. On OS X, ⌘ command+W only closes windows, but the application stays resident. One uses ⌘ command+Q to quit applications, instead. As the window is the application in Windows, Ctrl+W is kind of a misnomer, but it has gotten more popular for some applications like web browsers to support it.
Given the market dominance of MS Windows over Apple OS X for desktop operating systems, it would seem that the F4-style shortcuts are "more universal" than the W/Q ones.
Use CTRL+F4 to close current window, to close all window of visual studio and shut down use - ALT+F4 .
Go to Tools -> Options -> Keyboard Apply "visual studio code" additional keyboard mapping scheme
When a breakpoint is hit in Visual Studio, it steals the focus from whatever other application the programmer is viewing/typing into at that moment. This can be very irritating since VS grabs any keyboard input the programmer was typing into the other application at that moment and takes that input as its own.
What are the tricks you folks use to prevent this focus steal?
(I face this on Visual C++ 2008 and 2010. I am guessing it is a problem for Visual Studio in general and for all recent versions.)
This is finally fixed in VS2019. Go to Tools->Options->Debugging->General, down at the bottom is "Bring Visual Studio to the foreground when breaking in the debugger."
Just de-select it and you will no longer be interrupted while multitasking.
This is a registry setting. See ForegroundLockTimeout at http://technet.microsoft.com/en-us/library/cc957208.aspx. Zero allows applications to steal focus. TweakUI sets this value to 200000 when "Prevent applications from stealing focus" is checked.
For more control, download the Tweak UI utility of Powertoys for Windows XP. In the "General" tab, select "Focus" and check "Prevent applications from stealing focus".
Google search for ForegroundLockTimeout at http://www.google.com/search?q=ForegroundLockTimeout
Bing search for Prevent applications from stealing focus at http://www.bing.com/search?q=Prevent+applications+from+stealing+focus
Applications Stealing Focus on Windows XP at http://mycvs.org/archives/2004/11/16/applications-stealing-focus-on-windows-xp for screen capture of TweakUI.
Please Don't Steal My Focus, Coding Horror, Jeff Atwood at http://www.codinghorror.com/blog/2007/12/please-dont-steal-my-focus.html
The strange thing is, there are
provisions built into the operating
system to protect us from badly
written, focus stealing applications.
The ForegroundLockTimeout registry
setting is expressly designed to
prevent applications from stealing
focus from the user. The OS silently
converts that inappropriate focus
stealing behavior into friendlier,
less invasive taskbar button flashing,
which is the subject of the
ForegroundFlashCount registry setting.
How To Prevent Programs from Stealing Focus in Windows XP at http://www.howtodothings.com/computers-internet/how-to-prevent-programs-from-stealing-focus-in-windows-xp
Right click the breakpoint and select When hit ... this will allow you to run a function when the breakpoint is hit. You can use this to print status messages to the output window. You application will keep focus.
By accident I discovered a workaround, which I've been using for a few years now and while I haven't tested it in 2008 and 2010, it certainly works in 2013, '15 & '17 and at least Windows 7 & 10.
It relies on the fact that Visual Studio will not steal focus if another Visual Studio instance is paused in execution. Obviously the only thing as special as VS is another VS. :-/
Open a second instance of VS with a simple project. Pause the execution of the project anyway you like (e.g. put a breakpoint on the first line of execution and debug), you can then simply minimise that VS and none of the VS instances you're actually using will steal focus.
This is is obviously a heavy weight solution, but if you have ample RAM (the CPU usage of the idle VS doesn't even register for me), it works well. I haven't tried it with inter-version instances (e.g. pausing in '13 to make '17 behave), but if that works you'll probably want to opt to use the older version instance as your "dummy" VS to cut down on resource use.
One workaround is to use OutputDebugString() function to output current state into the debugger output window. You just place Visual Studio in background, position the debugged program window so that the "Output" window is visible - and no focus transition ever happens.
You will perhaps want to use macros for conditional compilation so that tracing code is not included into the release builds.
When developing on a system with dual monitors, I like to make the most of the extra space by stretching Visual Studio across both. It is fantastic to be able to see the Output, Breakpoints, Error List, Object Browser, and ReSharper windows at the same time without having to make them tiny and dock them in the main window, which leaves less space for code.
I place the main VS window on one monitor with the tabbed document and Solution Explorer windows. Any other windows I want to display are placed on the second monitor and docked together. The only problem I encounter with this method is that the main tabbed document window with the VS menu bar is the only window that can be maximized. The additional windows such as Solution Explorer, Breakpoints and Error List can only be stretched, docked or closed. I often go through the tedious work of selecting and laying out secondary windows only to have that layout be erased when I close VS.
Does anyone know of a VS add-in that gives you a window that (1) is maximizable, and (2) other windows can be docked in (ReSharper only does 2) ? Barring that, does anyone know of a good resource to learn how to develop VS add-ins? I am keen to do so myself if necessary.
I don't know of either of your suggestions, although I would also love to see better multiple-monitor support in VS. What I have done, though, is saved various window layouts (Tools > Import and Export Settings, and check only Window Layout) so that I can switch easily when I feel like it.