Visual Studio Window Docking

re: Visual Studio Window Docking

Craig — Thu, 05 May 2005 04:14:59 GMT

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

re: Visual Studio Window Docking

Gregor — Sat, 24 Apr 2004 13:27:00 GMT

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.

re: Visual Studio Window Docking

asdf — Fri, 23 Apr 2004 18:17:00 GMT

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

re: Visual Studio Window Docking

W Poust — Fri, 19 Mar 2004 20:36:00 GMT

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.

re: Visual Studio Window Docking

Peter Evans — Fri, 19 Mar 2004 14:55:00 GMT

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.

re: Visual Studio Window Docking

sara ford — Mon, 02 Feb 2004 06:29:00 GMT

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!

re: Visual Studio Window Docking

sara ford — Mon, 02 Feb 2004 06:25:00 GMT

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!

re: Visual Studio Window Docking

sara ford — Mon, 02 Feb 2004 06:12:00 GMT

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.

re: Visual Studio Window Docking

sara ford — Mon, 02 Feb 2004 05:58:00 GMT

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!

re: Visual Studio Window Docking

Andreas Häber — Wed, 14 Jan 2004 21:37:00 GMT

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? :-)