I support several Visual Studio 2012 MFC applications, and all of them are exhibiting the same bad behavior on Windows 10 only: resizing a docked pane (via mouse) leaves artifacts, i.e. garbage on the screen. The garbage looks like a series of lines that correspond to the intermediate positions of the pane edge being dragged. I can reproduce this behavior with a stock VS 2012 application, which proves that it's got nothing to do with my code. Here are simple instructions for replicating the bug.
In the VS 2012 New Project Wizard, select MFC Application and press OK. Accept the defaults for all options EXCEPT ONE: On the very last page (Generated Classes), change the Base class from CView to CScrollView. Then press Finish.
Now make the following edit. Find the line "// TODO: calculate the total size of this view" in OnInitialUpdate, in the view .cpp file. Change the size from 100 to 2000. The only purpose of this change is to ensure that the view has scrollbars.
Now run the resulting app under Windows 10. Try resizing the docked panes. Do you see the artifacts? They generally appear when the scroll view is getting BIGGER. Why is this happening? Would migrating to VS 2017 solve it? Or is Windows 10 now incompatible with MFC? Ever since I migrated to the "new" MFC (BCGSoft) features, I've been worried that their code is too complex and would break in some future release of Windows. It sure looks as if I was right to fear this.
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.
Is it possible to quickly hide what's on a particular monitor in Visual Studio? Similar to Norton Commander where you could easily hide left or right panel, I want to quickly hide all panels on one of the monitors to see behind them. Is it possible, maybe with a plugin?
Yes, you can.
For that, you need Visual Studio Professional and Productivity Power Tools extension. (You can install it with VS2010 Extension Manager)
PPT allows Floating Tab Wells: You can dock floating document windows on a separate monitor just like tool windows. There’s also an option now which allows you to open documents as floating by default.
Every Tab group has a minimize button. You can minimize the main window without minimize the tab floating panel, and vice-versa.
In my case, I have my main window at left and floating tab at right. If I want to see behind my right monitor, I just minimize the tab group only. With that I see the code at main window and whatever has behind the tab at right side.
For more information: http://blogs.msdn.com/b/visualstudio/archive/2010/06/10/document-well-2010-plus.aspx
Hope this helps.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Ultramon is a great program for dual monitors (stretching screen across monitors), but I was wondering if there is any way do to something in Visual Studio like have one tab of code open on one monitor and a second tab of code open on the second monitor with only one instance of Visual Studio running?
Or are there any other suggestions on getting most bang for buck on dual monitors and Visual Studio?
have one tab of code open on one monitor and a second tab of code open on the second monitor with only one instance of Visual Studio running
you can simply drag a Tab outside of VS onto your other screen.
Personally, I have my windows set up so that one my main monitor, I have the main visual studio monitor, so therefore my code window, maximized, with only the toolbox docked, on the left. This means the code window takes up as much space as possible, while keeping the left hand edge of the code close to the middle of the screen, where my eyes naturally look. My main monitor is a wide screen, so I find that gives me more than enough room for my code.
My secondary monitor has a second window, which contains the tool windows that I use. So I have solution explorer, error list, task list (//todo: comments), output window, find results etc. all taking up as much space as they like on my secondary monitor.
When debugging, the solution explorer moves the main monitor, and the watch, autos and locals windows take its place.
I find this gives me a very large area to write code, and really helps usage of all of those additional windows, by giving them more real estate than they'd usually have.
Update: In response to everyone talking about using the second monitor for documentation or running the app, I wholeheartedly agree, and forgot to mention how I do that. I use PowerMenu alot to acheive this. Basically I can right-click on any window and set Always On Top. So while i'm debugging, i want to see my output window, but then if I have to refer to some documentation, I just flick to Mozilla (on the second monitor), set it on top, and go back to visual studio. I find this lets me manage the tool windows without having to either shuffle them around a lot, or take up valuable space in the code window.
I have three monitors, so I usually run with this configuration:
Left Monitor: documentation / ebooks.
Middle Monitor: code / debugging
Right Monitor: Test application / scrolling logfiles (if needed)
This usually works pretty well, and since the monitors are fairly big I rarely need to use the test application in full-screen, so there's plenty of room for my tail -f windows.
I also use AutoHotkey to assign hotkeys that flip to the most important windows, like Firefox or my SSH session. That way I can simply use a shortcut key to access them when necessary.
The left monitor is actually a separate computer running Linux and keyboard/mouse shared with Synergy, so I have multiple ebooks or documentation pages open, one on each virtual desktop... I can flip between the documentation by moving my mouse to the left and using a shortcut key.
When I first got two monitors I wanted to do the same as you, use all the space for visual studio, but I think that you come to realize that it's best to keep VS on one monitor and use the second monitor for documentation, external resources etc. You wouldn't think it at first, but all the little touches like just being able to maximize other resources without them hiding your code is a great feature.
For GUI debugging is awesome being able to run the app into one screen and having the debugger in another screen. That's one of the most practical uses..
But really, depends on which kind of application you're developing, i.e., if you need to monitor open file handles, logs, etc.
I have VS in my left monitor and the GUI/running window in the right. However, if you want to have to code tabs open on each monitor, you could use UltraMon's option to expand a window across both monitors, then drag a code page over such that it puts up a divider. Then, you align that divider with the break in your monitors.
I've done that before, just to test it out. It's not a bad setup.
Three monitors -- all 1600x1200
Left: Email, IM, SQL Server Management Studio, Remote Desktops to servers
Middle: VisualStudio -- maybe multiple instances -- maximized, solution explorer and team explorer docked on right, errors/output docked bottom, others auto-hide
Right: Web browsers -- app debugging and normal web work, ADUC (if needed)
Other apps get moved around depending on what I'm working on and how crowded the monitors are and the interaction between the app that's open and what I need the info from it for.
I have three monitors, set up where Visual Studio is full screen on the middle monitor, the right hand monitor has all the tool windows configured and the left monitor is for browser, help, SSMS, email, etc..
Works well except if I have to remote in, so I have a separate exported configuration to bring move the tool windows back into Visual Studio, and one to set them back up for multiple monitors.
Though I use StudioTools for other purposes, it has a "Tear off Editor" option, with which you can "tear off" the file to a window and resize the window. Find it quite helpful
I find the Code Definition window absolutely invaluable to have open in my other monitor. As the cursor moves over a type name in your editor the other window shows its definition.
You could try right-clicking a file in solution explorer, Open With, and then go find devenv.exe. That will open it up in a new instance of VS. Plus, it saves devenv as one of your default options in the future, so you don't have to go hunting around for devenv all the time. Not beautiful, but an option.