Visual Studio Window Docking


As I’ve mentioned in my previous post, I’ve decided to use this blog to talk about topics besides Accessibility.  I’ve just recently taken ownership of window docking in Visual Studio, including tool windows and files opened in the editor space.

In VS 2002, 2003 (Everett), and Whidbey Alpha, window docking includes tool window docking, undocking, auto-hiding, floating, and so forth.  In Whidbey Alpha, we’ve introduced docking targets.  These targets allow users to quickly figure out how to drag and drop tool windows to new locations.

Feel free to leave comments here on your thoughts about our window docking model, especially any bugs or issues that have bothered you in past releases.

Comments (15)

  1. Aleksey Maksimov says:

    The thing I really miss in VS is an ability to expand docked window to whole screen. This kind of functionality could be seen in Eclipse – there you just double click on window titlebar and window will be zoomed, double click again – it will be restored back to normal docked state.

    This is very helpful for output windows. Most time you don’t need them, but sometimes you wan to look at whole picture without messing around with your workplace.

  2. Andreas Häber says:

    I’d like a way to use multiple monitors easier when writing code. I haven’t used Whidbey, so maybe this is implemented already?

    Anyways, in Everett it’s nice and easy to have code on one monitor and use the other monitor to show for example. But if I want to see a code file on each monitor I have to size the VS.NET window so it spans both monitors and then use "the new horisontal tab" feature and manually size it so it fits.

    I guess what I’d like is the ability to also be able to make code-windows float, like the debugging-windows can.

  3. Make tabs close when they are clicked with the middle mouse button, just like in Firebird.

  4. I second that, Aki. I middle-click tabs in VS.Net constantly because I’m so used to it.

  5. Anand says:

    This is a wonderful feature that I really like. The docking of a window in 2002 was really a art by itself. This feature in Whidbey takes the pain out.

  6. Andreas Häber says:

    A nice, IMHO, solution to the problem I described in a comment above would be to have the option to let a codefile behave like it’s a "Microsoft Office MDI style"-document instead (see http://blogs.msdn.com/pandrew/archive/2004/01/14/58417.aspx). But I suppose it’s too late to suggest something like this for Whidbey now.

    Orcas-feature maybe? 🙂

  7. sara ford says:

    Hi Aleksey,

    Interestingly enough, I discussed such a feature with my dev just a few days before you had commented. =) During design, i manually resize the Task List to appear maximized on my secondary monitor, and during debug, i do the same with the watch window. It would save me a lot of time to be able to maximize these tool windows on secondary monitors.

    I’ll put this down as a feature request for a future release. Thanks!

  8. sara ford says:

    Hi Andreas,

    Regarding your question about being viewing code files on another monitor without resizing the IDE, i don’t believe we have any functionality to do this currently. Depending on the code file, I’ll either 1. Open another instance of VS for the secondary montior, only showing the file(s) i want (no project) or 2. Expand the IDE across the two monitors, then do either Window.NewWindow if it is the current file i’m interested in, or just create a new horizontal group, as you mentioned above.

    Personally, I like the first approach better. I’ll have to pay more attention to why i do this, but i think i like having the shell opened so i have more control over the misc files i’m looking at.

    I’ll find out if there’s a way to get these misc code files on the second monitor without having to resize or create another instance of the shell.

    thanks again for the feedback.

  9. sara ford says:

    Hi Aki and Shannon,

    You’ve just given me a great reason to go to my manager on Monday and ask for a better mouse. Josh, hint hint.

    Seriously though, my current mouse doesn’t have a third button. Honestly, it’s been since college since i’ve used a mouse with a middle button, so i can’t "page-in" what it used to do. =)

    Let me do the research (and get a better mouse) and i’ll get back with ya’ll.

    Thanks!

  10. sara ford says:

    Hi Andreas,

    Are you asking whether we support MDI? Go to tools options environment general, and you’ll see an option to use Tabbed Documents (default) or MDI documents. Select MDI Documents. VS will prompt you to reboot. Upon relaunch, you’ll notice that all documents are in MDI. However, tool windows still have their previous behavior, being able to dock, autohide, and so forth. If a tool window is undocked (or tabbed document’ed for you whidbey folks), it will act as a MDI document in this state.

    Hope this helps!

  11. Peter Evans says:

    Here’s a pet peeve of mine about the VC++ enviroment which I believe is the same core technology just not as scaled up. It related to window docking so bear with me.

    Whats the point of HOT keys for tasks, output, code browser, help search, when they pollute the tabbing order of raw source files and do not all go away with ease. I am not sitting at the computer with the IDE installed at the moment, but I can give my full test cases examples if you need them.

    I like the sound of your feature you hint at which is kind of cooki cutter tool window placement/magic assignment of source to their place. Probably excellent for new code tasks and the stream line tasks of coding under the .NETF DECLARATIVE UI and MC world of the next edition (whidbey???)

    But there’s always the need to convert the old into the new and that requires being able to deal with some else’s bundle of files. So what would be nice along with the docking windows feature would be this. Methods for setting the clustering of documents in the IDEs windows traversal loops so that on open they get assigned to a specific loop of TAB next SHIFT TAB Previous.

    With all the navigation windows available the users could always get into another document set via the menu or any of these other feature rich utility windows.

    The other nice thing would be experimenting with having the possibility of having the same open window referenceable by more than one window traversal loop. That may be more confusing than useful, but the idea is that these clusterings could be defined at the project file level the solution level, the source file level or the user preferrred level. This is just a form of using the IDE as a navigation assistant, hopefully a better form than the arbitrary window-to-window traversal pattern of today, that is a dumb shift forward or shift back insert at current location mechanism with no assocative analysis of what else other documents are opened in conjunction with the current task or even task history or estimate of the intentions implied by the instantation of the new window.

    All and all its seems like with code browsers and everything else window traversal code be improved.

  12. W Poust says:

    One suggestion for docking windows is a way of setting up floating docking windows so that they automatically hide when VS is no longer the active window. Later when VS becomes active, they are shown again.

  13. asdf says:

    I’d love it for unpinned windows to just hide instead of animating away.

  14. Gregor says:

    Currently, auto-hide tool windows are shown when the user moves the mouse over those "labels" (whatever the correct term is) at the IDE’s edges. This can be annoying if the mouse cursor is moved just accidentally over such a label. I’d like to have an option to turn that off. IMO, mouse moves shouldn’t change anything on the screen except the mouse cursor’s position, tooltips, and occasional roll-over effects.

  15. Craig says:

    Can you tell me if VS.Net 2005 will have a control that implements the docking features and UI of Whidbey?

Skip to main content