When I'm working in Visual Studio 2010, the IDE seems to switch to "Scroll Lock" mode at random times. Is this a new feature that I'm not aware of (initiated by some designated key/mouse-click) or a bug? I'm guessing this is actually a computer/hardware glitch on my system, but wanted to check if anyone else is experiencing this issue?
After I'm in this "mode", I can't seem to get out of it. I've tried physically turning ScrLk on/off multiple times, highlighting text, etc. I 'crazy-clicked' my way out of it once, but have no idea how. At that point, my only option is to close the IDE and restart, then everything is back to normal.
it thinks the control button is pressed, so just press control and it should fix
Nope, it's a CTRL key bug... using the left key all the time and occasionally, VS2010 will freak out and let the mouse wheel operate independently for zooming rather than scrolling, Shift-F5 won't stop debugging, etc.
Solution for me.... hit the right CTRL key. Dunno why, but it made it go away.
This is certainly not a feature of Visual Studio itself. It is possible, although I would agree unlikely, that a third party extension is causing this behavior. To rule this out I would disable all extensions and see if the problem still occurs.
If it still occurs then I would grab another keyboard to test the hardware issue.
There is a known bug in Visual Studio 2010 that does this sort of thing.
The way I have experienced it is that the left CTRL key will get "stuck" in the application (it doesn't seem to happen with the right CTRL key).
When this happens, you start to get bizarre behavior (like the scroll lock effect with when you hold the ctrl-up/down arrows, or being unable to stop debugging because it will restart the application when you do SHIFT-F5, or you change the size of the code text when you use the scroll wheel).
Unfortunately, there is no fix for it coming in for VS2010. You have the choice of living with it, or upgrading to VS2012. Others have re-mapped some of their short cuts to work around these problems.
for those who have this problem and reading this..
I found a way to bypass this problem and all you need to do is-
close the little window of Properties in the right-down corner.
and no longer you'll have this bug. :)
Do you really mean ScrollLock? AFAIK VisualStudio does not change in behavior in any way in response to ScrollLock.
I suspect what you are experiencing is VS incorrectly believes one or more of your modifier keys are held (ctrl, shift alt). To correct this press and release each of the modifier keys one at a time while VS has focus.
Real example:
The app I am debugging has focus and I am holding the ctrl key for an in-app function when I suddenly hit a breakpoint giving VS focus. However VS appears to have not registered that I have released the Ctrl key so my first attempt to scroll within the document using the mouse-wheel results in my font dpi changing... (ctrl+wheel = zoom)
Fix:
Press and release the the modifier key while VS has focus.
I had this issue where the scroll wheel on my mouse would change the zoom percentage of my open code. Pressing ALT while Visual Studio was in focus worked for me.
The solution for me was to hit the left CTRL key. Dunno why, but it made the problem go away. This answer is different than the one above suggesting to hit the right CTRL key. I tried that first but it did not fix the problem. But when I hit the left CTRL key it did fix the problem.
Another option is to exit Visual Studio 2010 and start it up again.
I had this issue ever since I moved to another development machine, I thought my graphics card was the issue, almost had the boss order me new ones, as I could not get this resolved. Turns out closing the property window immediately fixed the issue!. My previous fix was to float all and not keep anything opened in the pinned tab area, which works, but is inconvenient.
Related
When switching between documents in VS2010 with Ctrl-Tab, the document switch window doesn't disappear until I've pressed tab multiple times to select an entry and then hit return. I'm sure that it didn't need the return previously: that the window only stayed up as long as you held down Ctrl and then when released it switched to the currently selected document. This is really annoying if you want to just hit ctrl-tab quickly to go to the last document.
I do have a few Extensions installed including Productivity Power Tools, Power Commands and VSVim, and I've also installed a couple of tools for investigating accessibility (NVDA, UIA Verifier in the platform SDK), so it's possible that one of these may have somehow changed the options.
So, my questions are:
Is the default behaviour of VS2010 that the document switch window only works while the Ctrl key is held down, or is my memory faulty?
If the default behaviour is as I remember, how do I get back to that?
I think this turned out to be an accessibility setting that was in a half-enabled state. In the Windows Accessibility settings I toggled the state of Sticky Keys a couple of times and now it's working correctly again.
This has just happened to me, and after some googling I found the solution: it was really the magnifier application I ocassionally started by pressing Win + Grey Plus. Once I have closed it the Visual Studio just worked fine without restart.
Regarding point 2.
Go to Tools : Import and Export Settings. You can then choose to reset the default environment settings again.
Also ensure than it's not an 'add-in' providing functionality different to that you expect.
Same behaviour with VS2012: when the Magnifier application is open (e.g. by pressing Windows logo key + "+" (plus sign)) this behaviour occurs even if the magnification is set to 100%.
You know the neat text zoom feature in VS2010 where you hold down Ctrl and then use your scroll wheel? Well, this seems to happen by default (and without ever pressing Ctrl) to nearly every file I open.
Usually I open a file and have to scroll to some lower point, but instead it starts zooming the text! I have found that by tapping the Ctrl key VS then realizes that it should scroll instead of zoom, but it's still very annoying.
Any ideas?
CTR+Shift worked for me.
(Works for Microsoft Office as well)
I believe they consider this to be a feature, and I haven't found a way to turn it off. I think it only happens if you are holding the control key while trying to use the mouse wheel, but I've found it gets locked in that mode sometimes. Personally I think this feature is anoying as &^%% and I wish they would take it out.
Check your Accessibility settings, you might have "locked" it down my accident
Under Windows 7 they are here:
Control Panel\Ease of Access\Ease of Access Center
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.
I am using Visual Studio 2005 with Team Foundation Server.
When I right click a file under the source control and choose "compare" VS appears to freeze until I hit escape. My guess is that the window that is supposed to be popping up is somewhere I can't get to. I tried minimizing all the windows that I can and it is nowhere to be found.
Try the keyboard shortcut to get to the window's main menu () then hit 'M' for move and hit an arrow key to attach the window to the mouse - then at the next move of the mouse it should jump to it.
Experiment with a window you can see first.
i had the same problem when trying to check in to TFS - no dialog and ESC escape key undid the freeze.
I had recently, before the problem, changed my Laptop + Monitor configuration as follows:
from Primary screen being the laptop and secondary screen being the monitor
to primary screen being the monitor and secondary being laptop.
I got rid of my secondary screen and tried again. SUre enough the invisible dialog was no longer invisible.
I had to disable my Second Screen as well. Now the check-in screen where you can add a comment IS visible.
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.