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.
Related
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)
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.
By default, in Visual Studio and in SQL Server Management Studio, Ctrl+Tab opens a navigation popup which lists all the open windows. The idea is that you can press Tab multiple times while keeping Ctrl pressed; as soon as you release Ctrl, the navigation popup disappears and the selected document is activated.
Unfortunately, as soon as you ever run Microsoft Narrator (text-to-speech reader), this behaviour changes. The popup no longer disappears when you release Ctrl; it waits until you press Enter to select a document. While I can appreciate this behaviour may be reasonable for blind people who are actually reliant on Narrator, I find it rather irritating that the behaviour has changed permanently and that the old behaviour doesn't return even if I stop using Narrator completely.
Is there any way to restore the old behaviour so that it doesn't wait for an extra Enter keypress anymore?
Be patient and it magically starts reverting to normal after not using Narrator or Speech Recognition for a month or so.
I know this is old, but still an issue with SQL Server Management Studio (SSMS) 2008 when Speech recognition is running on Windows 7 (32bit Ultimate).
Worse yet, there is no fix per se. As a workaraound, I exit Speech Recognition, and then ctrl-tab behaves as expected.
I saw a post for changing Narrator settings, but none of the settings in Narrator (text to speech) have any effect on the issue.
Maybe this is a dumb question, but I have the following behavior in Visual Studio 2005 while designing forms:
1 - Drop a control onto the form (suppose it's a Label, just for discussion)
2 - Drag that label to a specific location (aligning w/other controls, whatever)
3 - Release the mouse button
4 - The control is still stuck to the mouse!!!
To get it un-stuck from the mouse, I have to hit ESC, which restores the Label to it's original location.
This is driving me nuts. I literally have to use the arrow keys to move each control into place, pixel-by-pixel. I don't observe this behavior anywhere else in VS2005, nor do I observe it in the OS in general.
I am running on Windows XP inside a Parallels Virtual Machine, hosted on OS X. I don't think there is a driver problem though, b/c as I already said, no other apps demonstrate anything like this.
Please tell me there is some tiny checkbox buried somewhere that will turn off this behavior.
Sounds like you might have ClickLock enabled (or a similar feature). Try this:
Go to Control Panel in Windows
Open the Mouse control panel
Go to the Activities tab
Deselect ClickLock
If that doesn't work, maybe you have a similar feature in OS X?
This problem spread to other applications within my VM, so I reinstalled Parallels tools and it went away.
I use Visual Studio 2008. I haven't seen this behavior before and, as far as I know, I didn't change anything in the options.
When I press Start debugging all the possibly windows (watch 1 - 4), data sources, properties, registers (to be honest I have not even ever seen these windows before) appear in front of the code window and stay there after I stop the debugger.
Anyone has an idea what could be causing this ? (I am using CodeRush and Refactor for quite a while now)
When I close and restart visual studio all the windows are where they should be.
PS: Previously I have seen normal switching from normal to debug mode and back with some repositioning changes. That is the way it used to work. Now it is not. It has suddenly gone mad and when going to the debug mode it sometimes shows all possible IDE windows and sometimes not. When it does it no longer returns to the previous state. I cannot find this in the options anywhere.
Visual Studio remembers 2 sets of window layouts, normal mode and debugging mode. My solution is to arrange my normal windows exactly like I want them, then start debugging an application and once again arrange all of the windows the way I want, usually making it as similar to my normal layout as possible, then stopping the debugger and doing a File Exit so that VS saves my settings.
After doing that, it recalls my 2 different layouts each time.
I'm experiencing the same thing - whenever the debugger is running, switching focus back to the IDE immediately caused the debug panel to expand.
I ended up just pinning the debug panel so that it always appears when debugging, and just changing its height as needed.
To add to palehorse, another tip is Full Screen mode.