Should VS allow tool windows to maximize and minimize on secondary monitor?
Given the successful response rate of the first poll, I’m going to ask a similar and last question. I use VS on my primary mointor. On the secondary monitor, I use IE, test case writing and database tools, and the following VS tool windows: Task List, Output Window, and Watch Window. I’ve found myself wishing at times for a way to maximize the tool windows (instead of having to do this by hand), and sometimes even minimize the tool window, when i don’t want to minimize VS but still want to read the IE page behind it.
Do others want to be able to maximize and minimize tool windows on secondary monitor?
What other secondary monitor features do you want with respect to windows in VS?
Adding my disclaimer once again. I’m merely collecting this data as an experiement. It’s kinda late in the game over here, so no promises.
Thanks!
Comments
- Anonymous
May 20, 2004
It would be nice if they weren't always on top of IE on the test monitor. A nice feature would be the ability to map a key.. say ctrl+alt+n to move the selected VS element (the output tool window, for example) to the next monitor (a la the software "UltraMon", which lets you do that with entire apps, but not within apps) - Anonymous
May 20, 2004
Although I like the idea of maximizing and minimizing the tool windows on the secondary monitor, I'd like to be able to dock those tool windows to the edge of the screen in the secondary window, or I'd like those tool windows to have transparency so I can code behind them. - Anonymous
May 20, 2004
YES! - Anonymous
May 20, 2004
Docking on a secondart monitor would be very useful. - Anonymous
May 20, 2004
Minimizing and maximizing is all fine, but you know what would really rock my world?
Imagine choosing "Window -> New IDE Window" from the menu bar. A new empty Visual Studio .NET window appears. It contains absolutely nothing. I move this window over to my other monitor, and maximize it there.
Now, I can start moving anything I want from the original window over to the new window, including documents, toolbars, menu bars, tool windows - the whole shebang. I have total freedom and control. The new window isn't a new instance of VS.NET, but rather a secondary view into the same solution. I can distribute all the IDE elements across multiple such windows anyway I please.
This would give me the ability to maximize and minimize all VS.NET things on one monitor with one click, but also to dock things to edges of the other monitor, like others have suggested in this thread. I think docking would be difficult to implement in a natural and intuitive way unless there's a parent window with which to dock things.
This approach ought to be relatively easy and intuitive to use, since it doesn't add a lot of new functionality. It's basically just about the ability to open a secondary IDE window; everything else just sort of tags along for the ride. I also feel this approach is a bit more flexible. For example, instead of maximizing the secondary window, I might choose to position it so that it only consumes half of the monitor, leaving ample room for having a Word document visible while I work.
There is of course the matter of how you keep multiple instances of VS.NET apart in this scheme, but you also have to worry about that as it is (which tool windows belong to which instance). One obvious suggestion is of course to prevent moving IDE elements "across instances". It would also make things easier if the window titles of all IDE windows belonging to the same VS.NET instance were synchronized on project level. - Anonymous
May 20, 2004
I completely agree with Daniel Stolt. It would be really nice to be able to move any tab to the new window, including the code design or browser tab. So you could for example have two code windows on two different monitors or one code tab and one browser tab side by side with other tabs visible.
thanks for listening,
-raj - Anonymous
May 20, 2004
I've wanted similar thing that Stolt well explained into a variety of apps which need to have a lot of control windows visible. Usually they just allow to move some modeless window to the other screen but no docking of any sort and they tend to forget the window positions. Of course if the other monitor is not plugged in there should be alternate saved window positions for primary monitor etc, getting the whole package to work as one would expect will need lot of testing. I hope LH provides some facilities for allowing apps easier to do such things as that would be very useful in a whole range of big products like music sequencers for example. Some "standard" way could be laid out for allowing any window dock to any other window and to edge of screen etc. - Anonymous
May 20, 2004
Sara,
I have a suggestion for multiple monitor support.
1) Don't limit "multi monitor" to just 2 monitors. The ability to have code files show up on one monitor, help files & other docs on another and tool on the third would be helpful. That said, the ability to maximize/minimize tool windows would be helpful. BUT, i personally prefer to have the maximize/minimize feature on the monitor that holds the docs and help. I like to consolidate all docs, be it from VS.Net or from Online sources like Codeproject onto the same monitor. Makes finding the help much easier if its all on the same monitor.
2) Might I suggest, if you have any influence on this, a better approach to adding libraries and dll's into a project. Lib file addition is not intuitive and neither are dll's that are not COM. The whole principle of VS.Net in my mind is to allow ease of use and most of the students I have seen struggle with this part of using VS.Net the most.
3) Vs.Net also likes to delete or remove spaces for areas where it adds code itself. For example, just under the declaration of a class where controls are declared. I've noted that somtimes it will delete the spacing placed between the user declared variables and the control's variable that it creates. If auto generated code for that is placed in a REGION by Vs.Net automatically then it really could solve some frustrations for users.
3) Allow for the ability to separate the Designer and the HTML views for ASP.NET
Thanks for allowing me to provide some feedback. :-)
Cheers.
Sushant - Anonymous
May 20, 2004
Yes.
It would be nice if tool windows could be clustered together in a supplemental project specific tool window which location is recalled between sessions.
Also, allow this to work in a full screen mode instead of having the second monitor become dead.
More wishful thinking. Anything that makes the more aspect oriented nature of coding under managed code improved. - Anonymous
May 20, 2004
Yes, minimize and maximize would be welcomed additions. Also a way to have the secondary windows hide (or minimize) automatically when VS loses focus and becomes an inactive window. - Anonymous
May 20, 2004
Sara,
basically, i like the idea of an empty 'vs' window on a second (third,... ?) monitor that could be used to place any window i like. (tool windows, mdi windows, everything).
however, this approach has one major drawback: when debugging, where will my app be visible? incase both monitors are covered with maximized visual studio shells, there ain't much room left for my app. each time i'd click into one of the vs windows, the app will be in the background of an visual studio window... which is not helpful to say the least. (especiall when debugging drawing code ::)
so how about a dockable visual studio 'window area'. one yould have multple of those. they could be docked to any edge of the screen and resized toward the middle. the visible part would be able to contain any window i like.
if i remeber right, in the 16bit day, the symantec c++ compilers ide was working 'almost' like that. (except for the fact that it was crashing all the time ... :)
while this is a little offtopic, w.r. to your last post: what feature would i like instead of better multiple monitor support? well, it would be very nice incase the visual studio operation would be more reliable. it keeps crashing on me once a day. it doesn't build things the way it should. its extremely slow with certain build scenarios. its outright buggy in some areas. (just put a delegate before a form and try to edit the form. or build a form and add a tab control /w multiple tabs, delete a tab and check out what undo does to your code inthis case...) these are features i'd like to see some time spend on.
WM_MY0.02$
thomas woelfer - Anonymous
May 21, 2004
Sushant,
Have you tried using help as external (in VS 2002, VS 2003, tools->options->Environment->help->extenal help)? This does allow you to consolidate all your help windows (except dynamic help) as it launches help in a separate process.
As for maximizing across two monitors, I believe NVIDIA video drivers (or at least mine does) add an extra maximize button on the application window that maximizes the Window across on two monitors.
--
Cheers,
Saurabh - Anonymous
May 22, 2004
Yes, this would be very nice to have - especially with a hotkey to maximize or minimize the currently selected tool-window.
As someone commented above - you should keep in mind that Windows allows for nine (9) monitors connected to the system. If not there could soon begin to appear some funny bugs :)
Also, there seems to be a bug in both Visual Studio and Document Explorer which you can see when using multi-monitors. Often (I'm not sure when it happens and don't have any steps to reproduce the behaviour. Sorry for that...) a little, empty window appears in the corner of the window where VS is not placed. The window is empty (white border) except for min/max/close controls as a normal window. If you use them it affects the whole Visual Studio. It's quite annoying having this window hide the contents on my second monitor. I saw a comment about this on your previous poll-post, and thought I should give my version about this too. Sorry again that I don't have any repro-steps. Happends usually after having it open for a couple of hours/days...
Hope you take ideas from the comments in your posts for input to features for VS2005(too late I guess) and VS "Orcas"! - Anonymous
May 22, 2004
I've seen the bug that Andreas Häber is talking about a few times, too. As far as I can remember, it happens when VS.NET is maximized on a secondary monitor, then minimized to the task bar, and then restored. The stray window is left covering parts of the primary monitor, while VS.NET is restored to its maximized state on the secondary monitor.
And, I would suspect it only happens when you have the "Animate windows when minimizing and maximizing" setting turned on in Performance Options on Windows XP, but this is only a hunch...
What is particularly annoying about this bug is that the stray window isn't just a rendering flaw, it's actually a live window that you can activate and deactivate. Very strange. - Anonymous
May 23, 2004
Strange indeed. Also I was wrong above by saying that it has a white background. In fact the background of it is transparent. I had a window with a white background when it happend the day I wrote that comment :) Would be nice to see a fix for this.. IIRC I posted a bug report for the VS2002 beta, but I guess the input I gave then was not good enough for you to see the bug. - Anonymous
May 23, 2004
I tend to have the same set up with VS on the first monitor and tool windows on the second screen (except when I am debugging). I do find having tool windows over other windows annoying (for example, if I want to use VS and another app at the same time) but mostly it is OK. There are two things that could make this set up easier to use:
- a keyboard short cut to toggle all docked windows (so I can hide them in the rare cases where they get in the way)
- snapping to screen edges and other docked windows (so I can rearrange my docked windows quickly)
Jonathan