Locking toolbars

G. Man asked about locking toolbars in an earlier post:

<question>

My own personal complaint is the inability to lock toolbars. I cant tell you how often I accidentally drag a toolbar somewhere and hose up the IDE. I have to "reset window layout" which resets everything. And I have seen some developers not as particular as me who have completely trashed their toolbars and dont seem to care. They have their menu bar BELOW about 7 different toolbars, most of which are just blank space anyway...

</question>

I passed this question along to Jason Weber (jweber), who is responsible for this area of the product.  He had some interesting comments about some differences between VS and other applications that have locking toolbars.  G. Man still has an interesting suggestion, it's just that the definition of "locking" might have to be large enough to accomodate the dynamism that Jason describes.  "Locking" would have to mean something like "Don't let me mess this up -- I like it the way it is.  But you, you [IDE], you go do your thing."

<answer>

I’ve seen this request a couple times. It’s a great solution in IE or applications with a small number of toolbars that are fixed. But it doesn’t scale well to Visual Studio. We have about 60 toolbars of which 50 are dynamically tied to ui contexts. As you move throughout the IDE we’re constantly shifting the toolbars around based on your selection, editor, ui hierarchy and window layout. For example when you’re on a WinForm you see the designer commandbar, when you view the code behind it’s swapped with an editor commandbar, when you view the class diagram for that code it’s replaced with the Whitehorse commandbar, etc. Most customers don’t even notice the shifting.

</answer>

Thanks for the thoughtful suggestion, G. Man. 

By the way, VS 2005's support for importing and exporting profiles might be helpful with this, as they should enable you to configure your IDE the way you like it, export the settings to a profile, and then import/apply them if you accidentally mess things up.  I realize this isn't perfect, but I expect it will be much better than the "reset window layout" option you describe above.  I haven't tried this yet.  If I give it a go, I'll post again.

Happy C# coding!

--Scott

Comments

• Anonymous
  January 20, 2005
  Thanks!
  

• Anonymous
  January 20, 2005
  Thanks for the answer!

• Anonymous
  January 20, 2005
  Sorry for the double post!
  

• Anonymous
  January 20, 2005
  The comment has been removed

• Anonymous
  January 20, 2005
  You can move/copy your buttons to the menu bar, instead of moving the toolbar as a whole. Just open Customize window and drag the buttons to the menu bar (Ctrl+drag copies the button). However, from my point of view keyboard shortcuts are way more effective. I have my favorite set which i drag around from TurboC timeframe, thus i remove all toolbars from most of the IDEs I use

• Anonymous
  January 20, 2005
  Ever since I saw draggable toolbars, I thought they were "cool". I even think that treating a menubar as a toolbar and being able to drag that around is also "cool".
  
  However, I've yet to see anyone who actually does place their menubar in a location other than at the top of a window.
  
  Actually - that's not quite correct. Several years ago I was chatting to the HR manager at a small company I worked for. She was working on a PC with a 640x480 display and had MSWord open. She could only see a tiny amount of the Word document because she had 8 toolbars (some of them empty) docked at the top, but in such a way that they took up 8 rows. When I commented on it, she explained she didn't know how it happened and was unable to fix it - she thought it was a bug in MS Word.
  
  Now, I expect that most people using devenv won't ever get themselves in this situation, but a sizable percentage of the computer-using population will - and that's why draggable/dockable toolbars are bad. They are an incredibly bad user experience.
  

• Anonymous
  January 20, 2005
  "As you move throughout the IDE we’re constantly shifting the toolbars around based on your selection"
  
  - which is something which goes against all good UI design. "Always place a command in the same location". Imagine what would happen if sometimes the File->Save menu item suddenly shifted to the Help menu, or shifted to the right hand side of the menubar. That is basically what happens today when I click "Start" - a new toolbar appears which also has a Start button on it, but now has a stop button. So, to stop debugging I click the Stop button next to the start button. But that second start button is redundant!
  
  In this specific case, there should be a stop button that is greyed out on the main toolbar. In other situations, a new toolbar should appear the first time you change context, but that toolbar should by default be undocked. If you choose to close that toolbar, then it should be your responsibility in future to get it back again.

• Anonymous
  January 20, 2005
  Then perhaps another solution to the problem could be an "undo" for the last user-initiated UI-layout change?

• Anonymous
  January 22, 2005
  Seems to me that this is trivial to fix. Provide a "lock toolbars" option, and put a simple check in the toolbar's mouse-down handler: if "lock toolbars" is checked, don't start any toolbar-drag operations. The IDE would still be able to show and hide toolbars with no problems, but it would fix the problem of accidental dragging (but unlocking the toolbars would just be a context menu away).

• Anonymous
  January 21, 2009
  PingBack from http://www.keyongtech.com/2400028-way-to-lock-toolbar-in

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=scott-wiltamuth-s-visual-studio-blog-locking-toolbars