Multi Monitor Support in VS10

Multi Monitor Madness What would a perfect world look like where your using Visual Studio with two or three (or more) monitors?  One of the new Visual Studio 10 (Visual Studio 2008 = VS9) I'd like to nail is darn good multi monitor support, but I've got a lot more investigation to do to know what this would really look like.

Some of my favorite techie/VS bloggers are huge multi-monitor fans, like Scott Hanselman and Jeff Atwood.  I just got off the phone w/ Jeff and he mentioned a some good points (here are just a few).  Thanks Jeff

  • Live the Lifestyle, everyone should be using VS multimonitor on the team
  • Drag a tab to create a new floating window.  This would allow you to take some code or other document and move it wherever you'd like, onto another monitor for instance.
  • Nail the defaults.  Make the out-of-the-box default window layout experience rock.  Users frequently mess up their window layout.  If the defaults rocked, there would be less need for customization.

Some of the ideas we (our VS designers, myself, and architects) are thinking about are:

  • A Canvas. Being able to view many 'open files' zoomed out as if they were papers spread on your desktop that you could just click to zoom in and edit.  Search results would highlight code across the entire canvas of files.
  • Special Memory.  Ways to group similar files/dialogs/info/etc instead of just docking to the sides of the IDE.
  • Drag Zones.  Like many of the multi-monitor apps out there, how could this be applied to the VS IDE?
  • Tons of other little VS UI enhancements.

Personally, I haven't been bit the multi-monitor bug yet.  I love having one PC for everything (my laptop) which I dock and use a single external monitor.  I'm a big Alt-Tab & Win-M fan and like viewing simplicity, seeing just what I'm focusing on in view.  So my first task is to start trying a multi-monitor setup myself.

The reason for this post is to collect your feedback.  Now, early in the product cycle, before our plans are baked.  What would make Visual Studio rock on multiple monitors?

Comments (61)
  1. Allan Williams says:

    I absolutely love developing with multi-monitors.

    The primary advantage for me is to execute my application in one window and debug it in another. This has really increased my productivity. (That is until my boss got me a new, faster computer with only one monitor port. With a faster computer, my productivity is hurting…)

    The ideas that you listed above are a little too vague for me to grasp, so I can not really comment about them. Do you have any prototype pictures or even mockups that may explain it better?

  2. Mark W says:

    I think the IDE need a switch or handle the windows gracefully between multi and single monitors.  2 use cases come to mind: (1) hooking a laptop with an external monitor to extend the desktop. (2) connecting via Remote desktop (which forces the single screen).  

    We do quite a bit of Remote Desktop (both working from home and using your desktop in a meeting enviornment) and every time after RDC all my windows screw up.  Especially my VS IDE windows that I drop on my right hand side monitor (e.g. debug output, find results, stack view)

  3. Kevin Babcock says:

    I would LOVE to see multi-monitor support in VS. We can already undock windows and drag them to other monitors, but I’d like to see better support for this. I’d like to use all the landscape on my screen and maximize the things on the second monitor without having to drag it out to the size I want. I like the idea of having it "dock" or "snap" to the monitors as I move it around…that would make it easier to move around.

    I also like the canvas idea. In fact, I think that idea is great…I’d like to hear more about it.

  4. Sister Hannah says:

    That looks really cool! It’s like manny beautiful pictures put together.

                -Love ya!

  5. Yes! Please!

    Love the snap and canvas ideas.

  6. martinwoodward says:

    You can probably try out the multi-window lifestyle yourself for a bit by getting a laptop stand to place you laptop screen about the same height as your external monitor – then extend your desktop across both monitors, works quite well if not quite as good as having multi-monitors with same screen proportions.

    In terms of feedback – I have trouble thinking outside my current multi-monitor usuage style.  Currently I run my IDE full screen on the center monitor and then use the right monitor for thinks like viewing reference material (i.e. help or a code sample).  I keep the third monitor to the left to keep an eye on email / IM etc in a glanceable way without having to hide my editing window to tell if any of that stuff needs higher priority then what I am working on in my IDE window.

    When debugging an application, I have it on the right screen so that I can easily switch between IDE and app.  For some types of application, it would be nice if the console/test results windows were on the right hand side giving me more room to view code and watches etc on the center monitor.

    On thing I would say is that it is really annoying if your toolbars get too far from the window you need them with – i.e. if the toolbox for a windows forms design session was too far from your windows forms design screen.  I tried running Dreamweaver and Adobe Photoshop (which are kinda IDE’s of another type) in multi-monitor setup using undocked windows and it just wasn’t nice.  With all the apps I’ve used on the market today – keeping the windows associated with that application on one monitor inside a full screen app window prooves to be the way to go – but I think it could be improved.  You need only look at Powerpoint for an application that can handle muti-monitors in an innovative way (i.e. display slides fullscreen on one while keeping the slide editor/navigator on the other.

    Good luck – nice to hear some great imagineering going into VS10!

  7. Alan Stevens says:


    Occasionally I stretch the IDE across two monitors.  I like to split the ide into two sets of tabs by creating a new vertical tab group.  I’d love to have the tool split at the border of the monitor, automatically.


  8. noahc says:

    Lots of great feedback, thanks everyone.  If you get any more ideas, post them.  I’d love to show mockups or prototypes, but we don’t have anything to show yet.  But I hope to post ideas when we’ve got them better sketched.

  9. kettch says:

    I currently use three monitors. The center one runs Visual Studio full screen. All of my commonly used tool windows float in the right hand screen in a layout that makes sense to me. These include Properties, Toolbox, Pending Changes, Server Explorer, Solution Explorer, and Team Explorer. Certain windows are in logical tab groups.

    I also have several floating windows in the right hand monitor during runtime: Output, Call Stack, Autos, Locals, Command, Immediate, Breakpoints and Watches. Again, these are in a layout that works for me, with some of them tabbed together.

    I have certain less commonly used tool windows docked in the main IDE window, but always on autohide, code and designers get priority.

    The left hand monitor is where I keep reference material and other applications.

    I’d really like to see the ability to have certain window/tab layouts saved as presets so that you can toggle them. This would be useful for some of the scenario’s mentioned above where moving between different monitor configurations messes things up.

    Being able to open files in a floating window, and drag files back and forth between tabs and floating windows would be useful.

    One thing that would be most useful to me personally would be extra care taken to make sure that the floating windows all behave properly. I’ve submitted some bugs that existed in VS2005 and were carried over to 2008 that concern the positioning and behavior of floating windows. Unfortunately only the least annoying will be fixed for RTM. The other couldn’t be repro’d.

    Thanks! This sounds like it will be great. I can’t wait to be able to move off of crusty old VS2008. 😉

  10. Dan Lykowski says:

    I am currently running dual wide screen flat panels rotated 90 degrees to give me more lines per screen. I have my editor in one window, and my debugger/shell/cvs/datasheet etc open in the other.

  11. My friend and VSTS coauthor Noah Code has just posted a great article about the issues and opportunities

  12. Doug says:

    I agree with Alan on stretching the IDE across multiple monitors.

    When you have two code panes side-by-side any little adjustment to the docked windows can throw the splitter bar out of alignment with the monitor edge.

    It would be neat if the splitter snapped to the monitor edge.

    The snap would apply when dragging the splitter and when the window layout is recalculated.


  13. mdykun says:

    Multi-monitor is indespensible in my day to day development effort and currently it is easy to drag toolwindows onto different monitors. What would be nice would be the capability of dragging the designers out of the VS IDE and also the capability of creating new named doc containers. This would allow for different toolwindows to be docked or layed out and moved together in a grouped method. For instance I may want a debugging doc container, a formatting doc container, and so forth. For me having tons of little windows seems like it would have a higher cost then just draggable grouped containers.


  14. Dave says:

    I’ve been using three displays for development for several years.  

    Up through CS2, the Adobe apps made my life miserable with their floating palettes.  When I’d move the maximized Photoshop window, using UltraMon (or DisplayFusion now), the palettes would remain, making it an unnecessarily laborious task.  In CS3, they changed the palettes to a docked interface much like VS uses, and I find myself using Dreamweaver and Photoshop a lot more than before.

    To me, the most important thing would be that Visual Studio continues to change displays gracefully.  I find myself switching it between center and right display at least a few dozen times in a normal day.  I would hate if overjealous multi-monitor flexibility actually made it more inflexible to use in practice.

    That said, the canvas idea sounds excellent.  I’m already looking forward to it.

  15. dm says:

    My main monitor will always be the biggest one, in which I will run VS, but… when I run my app I would like VS to step back and yield the main monitor to my app and move itself to another monitor in case I need to debug.

    Being able to start my app on another monitor would also be nice.

  16. Josh Bernard says:

    I usually stretch the IDE across both monitors but my problem then becomes tool window placement. My toolbox or properties are usually anchored and its either on the far left or right. I would like to see something maybe where you can have duplicate tool windows attached to other windows. So I could have a web page on one monitor with a toolbox and properties toolpane inside that document window to reduce navigation time.

  17. Kirk Clawson says:

    +1 on the hotkey-to-switch-layouts. I use a piddling two monitors myself, with the main code window in the left, and (most of) the palettes on the right. It gets a little tight though. Ideally, when I’m unit testing I would like to hot-swap to a "test layout" that has my right monitor showing the test manager and test view and test results, then when I’m working on my DAL I want to hot-swap to the Schema view + Properties + server explorer. Then for presentation work, swap over to toolbox + properties + document outline, etc…

    That would be very cool

  18. jamey says:

    normally use a laptop with vs in the lappie screen and sql manager or web browser in the other screen but i could see myself wanting to use vs multi screen once in a while

  19. MSDN Archive says:

    Although multi monitor support sounds great, please don’t forget really key features that are still missing from VS, such as background compiling for C# and a less fragile form designer!

  20. JK says:

    My favorite idea from your list is to treat code files as individual windows. Why not treat code windows like toolbars, where they can dock inside VS.Net’s parent form, or can be undocked and float by themselves? Or something like squeak, where the layout is up to the user, and there isn’t a main work environment?

  21. Wim Haanstra says:

    I like the idea of finally getting multi monitor support in VS, but what I really do not get is, why do we have to wait until the VS10 release, which is probably not released before 2010 ? I have been using multi-monitoring as long as I got a job as developer, which was in 2001. We are still in beta testing of VS2008 and I tought the feature-freeze always started at the release of RC’s. Multi-monitor support is a frequently asked feature for Visual Studio. So why implement it this late?

    Ok, that was my frustration rant. I would like to at least be able to drag code windows to other screens. Maybe incorperate a compare function between two code screen too ? (like BeyondCompare does?).

    Also it would be great if we could have one window with HTML layout and the other shows the rendered page.

  22. Soporte Multimonitor para Visual Studio

  23. noahc says:

    Wow, lots more great feedback.

    kettch, it sounds like being able to dock those floating tool windows together in a group would help.

    Doug, good idea about snapping the splitter to natural edges, like between monitors.

    mdykun, I agree, documents should be able to float too.  I like the idea of ‘named docking wells’.

    dm, good point about moving VS or your app when running the app.

    Josh Bernard, multiple instances of the tool windows isn’t something I’ve thought of yet, thanks!

    Kirk Clawson, yes I agree and it’s something we hear a lot, that it should be easy to switch between layouts.

    JK, ‘squeak’?  I haven’t heard of that.  Funny you should mention the ‘all floating’ idea, that’s what the original VB v1 used and it’s better at multi-monitor than VS is today.

    Wim Haanstra, I agree that it is frustrating.  Very few changes were made in VS’08 to the actual VS shell due to other constraints.  It’s time to make some great improvements.  🙂

  24. noahc says:

    Many of you mention being able to easily switch layouts.  Has anyone tried the VSWindowManager VS addin? I’ve used it and find it very helpful.

  25. It’d be great to have multiple sets of tabs for code windows, grouped by project (or perhaps even user definable groups)

    Then you could just grab a set of tabs and move that set to a different monitor.

    The grouping by project would also help mentally to keep track of scope.

  26. Shital Shah says:

    How about putting a button near "X" in docable and floating windows to move them over to other screen?

    My preferred setting for multimotitors would be to have code windows in "Full Screen" mode on one screen and all other windows (Solution explorer, debug, output etc etc) docked in to some container on other monitor.

    The biggest problem however is "dumb" tab management in VS. As you browse over files very soon there are so many tabs gets and stays open that its pain to keep closing them. It would be nice to have setting for say, keep only 8 tabs open. In that case, when I double click on unopened source file, the tab which I haven’t opened since longest time should close.

    Another handy thing would be to have designer open on one monitor and code on another.

    In any case it is important to remember that lots of devs dock their laptops on and off several times a day to switch between single and dual monitor environments. VS needs to be smart about that.

  27. mcgurk says:

    My simple idea:

    You know how, when you drag tool windows, you get those neat little helper glyphs that float over the UI?  Make them multimonitor aware.  

    The current system:  Drag a docked tool window and five glyphs pop up within the UI.  Left, right, up, down and center (which has five parts).  

    Multimonitor aware system:  Drag a docked tool window and the same five glyphs pop up, but each monitor has its own set of glyphs.  Within the UI (on the monitor where the UI primarily resides), it behaves like normal.  Outside it fullscreens the tool window or snaps it to the selected side of that monitor.  If a tool window is already there and snapped to a side (or center) it is adjusted to fit the new tool window in the selected location.  Floating tool windows are not resized.

    This set of behaviors is simple to learn, as it apes the current behavior, but extends it to multiple monitors.

  28. Get rid of the MDI host environment altogether.  Have the "home" of the environment the menu and toolbar plus a "palette" from which you can "grab" editor windows, toolbox, tool window "containers" and allow the user to drag these to any monitor they choose and maxmimise it, snap it to a side of that monitor, stretch it across multiple monitors etc. When they minimise it it should minimise back into an "active palette" on the home window. The home window itself could be stretchable across multiple monitors etc just like all the other windows.

  29. Alun Harford says:

    I’d like to be able to have two ‘instances’ (probably really the same process) of VS running in different windows and drag-and-drop source files between them to move them. And multiple full VS windows open for a single solution would be good.

    I’d like it if I were able to dock stuff like the toolbar on a different monitor (eg. design a form in the centre monitor, have my toolbox docked on the right and side of my left monitor, and the properties box and solution explorer docked on the left hand side of my right hand monitor).

  30. A few suggestions!

    What about having multiple "workspaces" (like Linux’ multiple desktops) that allow you to open the files/tabs you want so that you can switch from working on feature X to feature Y without opening and closing the relevant files. Also being able to hide files/folders/projects in solution explorer for each "workspace" would be good so your solution explorer isn’t cluttered with files you never/rarely open.

    Also I would love for search results to by highlighted and incremental search. Also the ability to save searches (bookmark them).

    Another great feature would be the ability to collapse a code region from the bottom of the region rather than just the top.

    Lastly, when debugging it would be nice if all files/code regions/etc were closed after debugging is finished (a configurable option of course) so that you don’t have to close files that you’ve stepped into while debugging.

    Looks like you’ve got plenty of work to do!

  31. I did a vs survey a while back (thanks for the nice prize btw) and my biggest request was multimonitor support. It would be sooo nice.

    Having not to do shift-alt-enter all the time would save me a nice chunk of time, and keep me from developing some strange kind of pinky strain.

  32. SV says:


    Multiple tabgroups are perfect on my multiple monitor setup.  

    The concept is great – each tabgroup can be resized to take up a single monitor, and this works regardless of how many monitors you have.  The problem is that when the IDE flips between debug and code mode, the vertical tabgroup positions are messed up.  Try sizing them precisely to fit on dual screens, and you will see exactly what I mean as soon as you run your project in debug mode, and then go back to design/code.

    I can’t seem to find a pattern to it, but it seems to happen when the window is in a non-maximized mode.  I have tried many variations, including turning off all toolbox, output, properties, etc windows.  I have also added the same sets of tools to the top toolstrip to no avail.

    This is a royal-pain and makes me feel like I am developing with second-class software on my top tier hardware.

  33. Use Eclipse for about 10 minutes and you will understand how multiple monitor support for IDEs should work.  Eclipse is no where near the development IDE VS.NET is, but it nailed the whole multiple monitor aspect upon it’s creation.

    You can have multiple root windows open in different perspectives (coding, debugging, profiling, source control, etc)

    All based on the same solution –> completely linked in real-time.

    Visual studio needs the perspective concept as well as the multiple window support.

    Thanks for the great tools and btw currently I use several 24 inch LCDs to develop with as well.


  34. lynn says:

    Absolutley. Multi monitor would be very helpful.

  35. Will Shaver says:

    +1 for Multi-Monitor support

    I highly recommend reviewing Photoshop CS3 as they finally got it right. It looks and behaves like an MDI application… until you drag a window all the way out, and SNAP it will jump outside the box and into your other monitor(s). (And will maximize correctly on that monitor as well.)

  36. James Wyatt says:

    Finally, looking forward to it and it should have been done ages ago.

  37. NIck Wilks says:

    I have used 3 monitors for the last 5 years or so. I initially started out with it because i could but being a web app developer, i feel that i benefit hugely from SQL, VS and Browsers on independant monitors, when I am just in VS though I hate the fact that I can’t compare different file versions  withoug opewning multiple editors.

  38. Jules says:

    My thoughts:

    When I’m not using VS, I tend to use Eclipse.  It has a very simple facility that makes it usable on multiple monitors: a menu item to create a new top level window.  Once you’ve done that, you can put one window maximized on each monitor, set whatever collection of toolbars you want to have on each window, and use them for different purposes.  (I actually ended up here by googling to see if Visual Studio had a similar feature.  Clearly not.)

    Now, this isn’t perfect.  A few flaws I spot in this are:

    * If you’re working with a file in one display, but then do something in the other display that references it, you end up with two copies open.  I’d prefer it to be brought to the front on the side of the screen I’m working with it on, and some method used to draw my attention to that.

    * It isn’t possible to drag and drop between the two windows, which is a pain.

    * Only one of the windows switches layout when I start debugging; ideally, both should switch together.

    This is better than stretching a single window over both desktops (as some of the posters above are clearly thinking) because it copes with unevenly sized desktops (e.g. if you have the taskbar permanently displayed on your primary display, but not on the secondary).

  39. jason says:

    I love multi monitor, but rarely use it with VS.  When I put the Soln Explr, Schema view, Watch windows or what ever in the second montor and then debug, then stop debugging, all the windows come back into the main window.  if they would stay in the window i dragged them to in the first place, that would be great.

    also being able to detect multi monitor..   i develop all day on three monitors, but then take my laptop home where i only have the laptop screen

  40. jmr says:

    All I really need is a separate top-level window that I can drag tabs to and from, like Jules talks about in Eclipse.  

    If VS had that, and the contents of all windows switched on mode-changes (ie debugging, code editing, etc), life would be nearly perfect.

    Is it possible for a third party vendor to create something like this?

  41. Matt Dotson says:

    I love the idea.  VS is just too complex of an app to use on one monitor.

    But please remember that people using laptops with multi-monitor support sometimes start their laptops up without the second monitor attached.  Please support us switching between multi and single montiors easily without having to recofigure my docking preferences every time.

  42. ben says:

    I happen to have 3 monitors on my development box.  They’re all of the (near) 4:3 variety but two of them are rotated (Portrait).  If there is a mix of portrait and landscape displays, it would be nice if VS ‘preferred’ portrait monitors for code windows and landscape monitors for design views and tool windows.  Also, if there are 3 or more displays, it should pick two (preferring portrait) with the same resolution that are adjacent with and creat a tab group on each with the split held at the border.

  43. Đonny says:

    I thing that possibility to clone main VS window to other monitor and freely move tabs and dockable windows between those main widows is quite enough.

    Another think I’m interested in is possibility to save multiple VS dockable windows (and dockable windows turned to tabs like Object Browser or Team Eplorer) configurations and switch them quickly.

  44. Greg says:

    It would be really nice to have

    a. multiple top level windows

    Each top level window has the full tool bar, a tabbed documented area, and floating windows.

    The tabbed document area should be able to be disabled so you have a collection of tool windows.  This is preferable to the floating tabbed window collection which does not have its own z value.

    Each top level window should have a layout.  VS currently has Design, Debug, FullScreen, and NoToolWindow.  There should be Windows commands and a drop down tool bar for naming new layouts.  Layouts should store the location of tool windows, and the context of a tool window (memory view layout).

    There should no longer be limits on the number of watch and memory windows.  The settings for each of these windows should be persisted in the layout.

    Having multiple top level windows allows the user to maximize a window to each monitor.  This is preferable to stretching across multiple monitors.

    Layouts should be data driven, not programmatic.  Eclipse perspective are programmatic and very annoying.

    Top level frames should be able to share documents and tool windows.  The user should be able to drag a window from one frame to the other.

    b. Multi-monitor Debugger

    Each top level frame should be associated with a debugger context.  Per frame the user should be able to specify program, thread, and stackframe.  There should be simple rules for defining on which frame a stop event opens.  Multiple program and multi-thread debugging is not friendly in current VS.  This needs to change.

  45. TheXenocide says:

    Multi-Monitor Visual Studio would rock my socks! I haven’t amicably developed without an additional monitor for 5 years; it just opens up productivity at least two fold. If you guys can go so much as to make it 3 fold that would be great, but based on the pool of interest here I’m thinking it may be more like 10 fold.

    Best of luck, I’m rooting for you.


  46. Mike Gibson says:

    Are you guys going to actually commit to adding multiple monitor support in the next release?  The developers have "asked for our feedback" on the multi-monitor thing on every single release since vs7.  We gladly provide it.  We submit feature requests as asked.  We rank those requests and "damn important".

    But then the feature is quietly ignored.  What else do you want us to do?

  47. Would give my left arm for multi-monitor support implemented well in VS. My current dual monitor setup for coding is; left master monitor hosts the main IDE window, the right slave monitor hosts all the floating tool windows. the Main IDE window usually shows two code tabs side by side.

    Would like to be able to drag code tabs to the second monitor and have it then resize automatically to fill the screen.

    The problem is what to do with the floating windows, do you leave these in the origional confiruration on the master window with the slave just an empty window no menu bar etc but with the ability dock other windows or do you replicate the master window layout including docked windows to the slave resulting in what looks like 2 VS instances working on the same solution?

  48. I think this is a good idea, but I wanted to echo Mark W’s concerns about support for Remote Desktop. VPNs are pretty common these days. Thanks!

  49. Khash says:

    I use a three monitor setup for development and I love it. Middle monitor is for the code, left monitor for the explorers (solution,… anything tree like) and the right monitor is for toolbox, properties and output windows. This allows me to have maximum coding space while being able to see the bigger picture at the same time.

  50. Austin Donnelly says:

    I use two wide-screen monitors, rotated 90degs to give me nice tall displays so I can see lots of code.

    Normally I have VS "full-screen" on the left-hand monitor, and reference material, shell, RDP session to test box, etc on the right-hand monitor.

  51. Eric says:

    Thank you for considering multi-monitor support for VS10. You have no idea how long I’ve waited for it in Visual Studio – every developer at my current job, as well as my previous one, has had dual 19" LCD monitors.

    At a very basic level, the only "true" multi-monitor feature in Visual Studio that I need is the ability to drag a window out of the MDI interface and have it become a true, top-level window.

    I have two ideas on how multi-monitor support could be added to Visual Studio. The first idea would be a "low tech" modification to Visual Studio, while the other would allow for a "rich" multimon experience.

    Idea 1 – "loose" windows

    * Allow document windows to be changed to top-level windows and vice-versa

    * Add a new context menu item for the current document named "Change to Top Level Window" or something similar

    * Add a new keyboard shortcut to do the same thing

    * Implement "drag" support to the current document’s tab, allowing it to be "dragged out" of the Visual Studio MDI container and "onto" the desktop as a top level window.

    * Each top-level document window appears in the task bar independently (rationale: Some multi-monitor tools create a taskbar for each monitor)

    * The windows should act, look, and feel like "normal" windows – show in the task bar, full sized OS drawn title, etc. (Not tool windows)

    Idea 2 – Multiple Visual Studio MDI windows

    * Add a new command under the "Window" menu named "New Visual Studio Window", or something similar

    * Add a new keyboard shortcut to do the same thing

    * Selecting the command creates a new Visual Studio MDI window.

    * The new window would have a full copy of the Visual Studio menu (ie/ each top level Visual Studio window gets the same menu)

    * The new window would not have any toolbars. Each top level Visual Studio window would have a different toolbar configuration, but could have duplicate toolbars. For example, Window 1 could have the "Standard" and "Text Editor" toolbars enabled while Window 2 could have "Standard" and "Debug Location" enabled.

    * Only one Solution may be loaded (no change to current behavior. Additional solutions can be loaded by opening other Visual Studio instances, the same as current behavior)

    * If an item is opened using the menu (ie/ File->Open), it opens in the active/current window

    * If Solution Explorer is docked to a Window, items opened using Solution Explorer open in the same window (same as opening in the active/current window)

    * If Solution Explorer is not docked to a window, items opened using Solution Explorer open in the "first" window

    * Document/text child windows can be dragged between Visual Studio windows

    * Add commands/context menu items for "Move to Visual Studio Window #2", etc.

    * Once a new Visual Studio MDI window is opened, the title of each window becomes numbered (Project – Microsoft Visual Studio – 2).

    * Each Visual Studio MDI window appears in the task bar independently


  52. Brian says:

    I haven’t gone through the entire thread just yet. I think it would be nice to have the ability to add secondary Visual Studio parent windows. Then you could move and dock other screens from one parent window to another. A user with multiple monitors could put a parent window per monitor and arrange their documents and various other windows however they want.

    Another option would be to drop the main window all together and allow for windows to exist by themselves. The windows should be capable of being grouped. This includes the main menu bar. A user could group their toolbars and source code, while being able to move a single document out of the group to another monitor. Each group of windows should show up on the task bar for easy access. I suppose this would be similiar to SDI mode in Visual Basic 6. Being able to group windows with tabs to move between windows in a group would be an improvement on that design.

    I can’t say I’m a veteran programmer but I thought I’d put out my ideas.

  53. Brad Dodson says:

    I have two monitors and generally I’m editing on one, and using the other to hold open reference materials, command-line, etc. I generally keep all the tool windows close and then just use the hotkeys to open them.

    Thus my feature requests would be:

    In addition to the ability to have code windows on both (or several) monitors, it would be excellent to be able to set the Go To Definition (F12) functionality to open the definitions on a secondary monitor (that way I can trace through definitions while keeping my editing context.

  54. Rob says:

    "In addition to the ability to have code windows on both (or several) monitors, it would be excellent to be able to set the Go To Definition (F12) functionality to open the definitions on a secondary monitor (that way I can trace through definitions while keeping my editing context."

    You, sir, are going to be very excited when you discover the Code Definition Window in about 30 seconds.

    In response to Noah’s blog:

    Clearly, the tabbed document window(s) not being a "Dockable" tool window is the most pressing issue.  Simply making this a tool window will not fully address the problem, though.

    Currently, in VS9, there is no way to dock a group of tool windows inside another tool window.  In other words, no virtual tool windows.  This should be remedied in VS10 in order to complement multimonitor support.

    To demonstrate this, I would invite anyone to create a cluster of free-floating "Dockable" windows, then take that group of windows, all nicely configured, and drop it on a single "Dockable" floating tool window.  The result is nothing short of disastrous.  You end up with one window that has a zillion tabs at the bottom of it, instead of one window that has two tabs on it, with the second tab being the group of tool windows that was just dragged.

    We have anonymous methods…  Now we need anonymous tool windows!  =D

    I’m one of those guys who likes to have every tool window that I use open at all times and docked somewhere so that I know exactly where it will show up when I hit my hot key.  I detest floating windows.

    To me, the ideal IDE would be completely made up of dockable windows.  Including the menu bar and tool bars.  They should both live inside dockable windows.  That way the few toolbar icons that are actually useful to an experienced developer can live next to the few menu groups that are actually useful and thus take up as little space as possible.

    Also, I *hate* the fact that VS9 remembers different tool window positions for different viewing modes and there is no simple way to disable it through the IDE or even force one view mode to adopt the positions of another.  This should at least be optional.  I would much rather see a generic, scriptable, event driven interface whereby people can setup their IDE to auto-import configuration files when certain events are fired, be that opening one type of solution versus another, or opening a tagged file, or switching view modes.  It shouldn’t take an add-in to accomplish that.

    All told, the multi-monitor support existing in VS9 is not terrible.  It’s better than its ever been, and I know…  I used SDI to multimon long before the new IDE came about, and that was truly awful.

    The main problem is that it is not at all intuitive to configure.  There is no APPARENT support for multi monitors.  No commands to move windows to alternate displays.  By chance someone has to figure out that "Dockable" really means "Floatable To Your Other Monitors And Sticky Like The Devil If The Devil Could Be Cloned And Stuck To Himself" to get a good multi-monitor setup going.  Don’t ask me why the devil is sticky.  Ask the devil.  Yes, he’s the one who made me type so much.

    Thanks for all your hard work, Noah.  The VS9 IDE is great, for C# anyway, and I am sure VS10 will be even better.

    Kick the guys working on C++ intellisense in the seat of the pants for me if you happen to pass them in the halls.

  55. Rob says:

    Oh, one other slight thing:

    Currently, if you create a new tab group within the IDE’s main window, as soon as all the documents are moved out of that tab group or closed, the tab group disappears.

    For tab groups to work as tool windows, this behavior would need to change.  It might still be acceptable for tab groups that are docked in the main application window, VS9 style, but if a tab window is turned into a dockable tool window, it should persist when empty.

    Furthermore, windows need to remember where they live.  A document that is opened in a docked tab window should continue to open there until it is moved from the window, the window is closed or perhaps the IDE is reset.  It may not be necessary to persist between restarts of the IDE, but at the very least, it should be persisted for the session.

    Last, and I really will shut up this time, I promise: I just want to throw my vote in for something another guy mentioned, which is that it would be nice to be able to specify where code windows opened by specific methods are displayed.  For example, Go To Definition could be assigned to a particular tab window, but Solution Explorer could be assigned to another, and Open File could be assigned to another.  This saves people the trouble of hitting the "Move To Adjacent Tab Group" hot key (Which will exist..  right?  :D).

    It is fun to play the demanding customer for once…  Ok, back to work.

  56. Chris says:

    Better Multimonitor support?

    I have been utilizing a 4 monitor development system for over two year.  Many developers at work have multiple 2 or more monitors.  It seems multimonitor support has been going in the wrong direction.  Things were fine in 2005 and 2008 degraded. and now 2008sp1 has down right P1 bugs.  Yes please get this stuff working again.. cause I like pixels and multiple monitors are the fastest way to more pixels.

    Honestly, I dont worry about tabs or docking.. just setup most of your views into floating and then drag them to the other monitor.. you can then attach other windows to them.. I have a floating window on each monitor with multiple things attached to it..


  57. Carlos says:

    Dreamweaver has had multi monitor support and customizable windows layout since 2003.

  58. Jacob says:

    Hello  i just got heavy into computers, i just built this one my self(save for the mother board) but i put in 2 Radeon HD video cards and they both have duel monitor ports, I was just wondering is how do i get each to work, I see pictures of people with just one keyboard and what not but not sure how to use each one really. Any help on this would be GREAT!

    My e-mail is

    I already know how to set them up but be for i go messing around and screw something up i’d like someone to give me a step by step or any info they can.

    Thank you so kindly for anyone that helps me out!


  59. Tom says:

    Hi thanks for taking our comments!  I would love to see VS support multiple monitors.  

    Personally, I would like to see all the code on one monitor and my solution explorer / tools / properties / output / test results / compile errors and so on in another (or multiple other) windows.  If I am editing XAML or something else that has a graphical representation then I would like to see the code I’m editing in one window and the graphic in another window.  

    In a related note I often have two Solution windows open at a time because I write our generator code (using C# to generate C#).  It would be nice if in this multiple window world I could have one set of Solution Explorer / tools / etc (see list above) that update as I switch from solution to solution.

    Again Thanks

  60. scott says:

    My thoughts:

    After having 2 monitors for the past several years, I have one key comment to make:


    Yes, I have strong feelings regarding this subject.

    Some possible sets of usage modes:

    First and foremost: 1 monitor support

    Second: 2 monitor support

    Third: multi-monitor support

    First Usage Mode

    Don’t break what exists. This works today so don’t break it.

    I have 2 monitors on my desktop, and a laptop.

    Using the laptop for portable development, and the desktop when I have time.

    Second Usage Mode

    Debugger & selected tools on one monitor, editor on the other.

    This is what I would like to be able to do today.

    Yes, you can hack your way to making things sort of behave this way in VS 2008.

    Third Usage Mode:

    Things get interesting here, as far as I am concerned.

    Basically, it amounts to not getting buried in multiple windows on one monitor.

    scenario 1 :

    Second Usage Mode+1 Monitor for browsing.

    scenario 2 :

    This one goes more to the debugger capability.

    First Usage Mode for each application layer — debug across application layers in parallel.

    This would be very helpful for asynch debugging across n-layer, n-tier applications which are becoming the de-facto model for enterprise development.

    scenario 3:

    One for each monitor.

    Debug, Code Editor, XAML Editor, XAML Designer

    Thank you very much for asking the question.

    Hope this helps.

Comments are closed.

Skip to main content