I'm wondering whether other users of VS2010 are experiencing the same problems as me.
I find I have to restart VS several times a day after the XAML editor becomes unresponsive to mouse clicks. I've tried submitting a Connect issue but got nowhere with that.
My environment is:
Quad core machine runing Vista 64 with 8GB RAM.
VS2010 SP1 - had the same problems with VS2010.
ReSharper 5.1.3
Editing Silverlight XAML files - I have the split screen with preview at the top and the XAML at the bottom. After some time of working, if I click in the XAML the carret doesn't move to the clicked position. Other parts of VS are unresponsive to mouse clicks as well. Basically I have to shut down VS and restart.
Of course, this is difficult to reproduce - it generally only happens after several hours of running.
Anybody got any ideas on how to fix this, or better bring it to Microsoft's attention?
Update:
Here's the link the the Microsoft Connect item I entered.
http://connect.microsoft.com/VisualStudio/feedback/details/618594/xaml-designer-stops-responding-to-mouse
This is a very common problem, you should check out some other references, but a few thigns you can do are;
Replace the XAML editor with something else (Blend maybe)
Right click on a XAML file, goto "Open With" then select an alternative editor and also select the set as default option.
Open the XAML editor in Full screen source mode by default. This will bypass a lot of the design time compilation's
Close other windows, in visual studio when your editing the XAML, perticularly the properties display. I've found that this window frequently queries the design time model of your code to display properties and such (if you dont want them triggering all the time, close the window and that thread will be idle).
Good Luck!
I've had similar issues where the mouse stops responding on certain windows when resharper is running. The only solutions I've found so far are:
Hit the ALT key (discovered the mouse becomes active after this, but you have to keep hitting it every time you switch windows)
Restart visual studio
Disable resharper
Update:
This is essentially a Vista 64 problem but ReSharper exacerbates the problem through large memory use. Upgrading to Windows 7 64 bit solves the problem.
Related
this has been bugging me for quite a while now.
I'm using two monitors and usually have the main window of Visual Studio open on the primary monitor and things like the solution explorer, call stack, error list, output etc. on the second monitor in two separate windows which I split vertically by using the [Win] + [Left | Right] shortcut.
In another environment, this works fine (VS 2013, different machine). Of course, the window positions etc. are different between debug and regular view, but that's not really an issue.
Whenever I start debugging, the solution explorer window moves towards the right on the second monitor. This might even affect the other window (which contains the Call Stack, Output etc.).
After a few debug sessions, the window will be barely visible any more because it has moved so far towards the right...
This is even worse when I have multiple solutions open because then the solution explorer window that I see is actually the one from the instance in the background...
Has anyone else experienced this? Any ideas how to fix this?
P.S.: I'm working on a windows server via a RDP session, maybe that contributes to the problem.
The following worked for me.
Under the Windows menu, save the desired layout with "Save Window Layout". I named mine "Debug". This might have something to do with the old layout names.
Stop debug mode if your in it, and apply that layout with "Apply Window Layout".
Start debug mode.
My un-docked windows flash as if they are resizing, yet stay where I had them in the saved layout.
This question is solely about workflow in VS2013. In VS2012, when I would build my app, VS would display the app on the second monitor attached to my system. This was nice because I could see my IDE while I interacted with the app. However, in VS2013, the app always just displays over the IDE, so I have "move it out of the way" just to get back to the code. I would like VS2013 behavior to match that found in VS2012. Is there a setting in the IDE that I can switch on to ensure the app displays on the second monitor?
I did find another question on SO about this regarding VS2012, but the solution there does not work for Win8.1 using VS2013. Is there an option for this?
it's not exactly the answer to your question - garaber has already addressed that - but also useful in this context is that you can move a window to a different display using the keyboard -
windows-shift-left arrow
and
windows-shift-right arrow
fast, easy way to move a window to an adjacent display (either to the right or the left)
EDIT:
should have noted that this is not confined to visual studio - this is a feature introduced with windows 7 and works with any window.
Here's a couple of good links that will show you how to do what you're wanting:
Save and restore form position and size
Restoring window size and position with multiple monitors
You can also change your principal screen, and it works :
In, Screen Resolution : set your second screen as a principal screen.
In visual studio 2010 professional, when I maximize the window on a monitor that is 2048 x 1152, Windows 7 changes to the basic color theme (disables aero). Most of the time now I manually resize the window to be the full screen, just not actually maximized which gets around the problem, but is quite annoying.
Maximizing to one of my smaller 1680 x 1050 monitors on the same machine does not cause this problem.
Done quite a few searches with no results... Any ideas?
To fix disabling of Aero when VS2010 go full screen you need disable
"Use hardware graphics acceleration if available" in
Tools -> Options -> Environment -> General
First off, the blanket suggestion is to try upgrading your video drivers.
See this issue submitted to Microsoft Connect:
Resharper and XAML: http://connect.microsoft.com/VisualStudio/feedback/details/567407/visual-studio-2010-switches-to-basic-color-scheme
And this post on MSDN:
http://social.msdn.microsoft.com/Forums/en/vswpfdesigner/thread/974a0645-53e2-47bf-9463-69b1119bffd3
One thing to try is to run the Aero Troubleshooter. You should be able to get to it by clicking on the balloon and reading the help (there is a link to it there, search for "aero troubleshooter" if you don't find it right away) or by searching for aero in the control panel.
On my laptop the troubleshooter reported that it had changed "something" (god knows what) and then the problem disappeared... magic!
/AZ
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.