Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Feature Requests

VAX toolbar and debugging

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
thruska	Posted - Aug 30 2006 : 12:55:29 PM I've done enough COM interface programming to know that Microsoft makes this really hard to control (at least from the Office toolbars), but the positioning of the VAX toolbar shifts every time I start debugging and then stays put when I finish using the debugger. It would be nice if it jumped around depending on the mode of the IDE and simply stayed where I put it in each mode. It isn't a big deal except when I'm not debugging the toolbars aren't "visually appealing". I don't know how much of the toolbar interface is exposed to the VS.NET IDE or if knowing what mode you are in to jump around is even possible, but it would be great if VAX memorized the various positions I put it in for different modes.
6 L A T E S T R E P L I E S (Newest First)
kevinsikes	Posted - Oct 05 2006 : 04:57:21 AM I finally buckled down and poked into the innards of the VS.NET 2003 object model to duplicate the VC6 behavior of hiding the Build toolbar while debugging. The VBA macros are fired by Debugger events: Imports EnvDTE Imports System.Diagnostics Imports Microsoft.Office.Core Sub ActivateBuildToolbar(ByVal bShow As Boolean) Dim bld As CommandBar, dbg As CommandBar bld = DTE.CommandBars("Build") dbg = DTE.CommandBars("Debug") 'always hide the visible one first, so the toolbars remain 'in the same position If bShow Then dbg.Visible = False bld.Visible = True Else bld.Visible = False dbg.Visible = True End If End Sub <System.ContextStaticAttribute()> Public WithEvents DebuggerEvents _ As EnvDTE.DebuggerEvents Private Sub DebuggerEvents_OnEnterDesignMode(ByVal Reason As EnvDTE.dbgEventReason) _ Handles DebuggerEvents.OnEnterDesignMode ActivateBuildToolbar(True) End Sub Private Sub DebuggerEvents_OnEnterRunMode(ByVal Reason As EnvDTE.dbgEventReason) _ Handles DebuggerEvents.OnEnterRunMode ActivateBuildToolbar(False) End Sub The Microsoft.Office.Core namespace is for declaring the CommandBars references. If for some reason this package is not included with VS.NET 2003 by default, omit the Imports statement and the associated references, calling code like this instead: DTE.CommandBars("Builds").Visible = False It's been a while since I've had a good wrestling match with the IDE. I'm happy to say I came out on top this time , although not without some sleep deprivation. (The macro code itself wasn't hard to write, it was deciding if the code needed to be written in the first place that was laborious -- searching Google for "visual studio" 2003 toolbar layout returns 168,000 results!)
jpizzi	Posted - Aug 31 2006 : 11:05:23 PM Now that I think about it some more, I was (mis-)remembering a feature of WndTabs (closing windows opened during debugging). And I was sooo looking forward to that quarter
kevinsikes	Posted - Aug 31 2006 : 08:13:59 AM Joe, I've got a shiny quarter for you if you can remember and point me in the right direction ;) This has been driving me nuts since I upgraded from VC6.
jpizzi	Posted - Aug 31 2006 : 12:09:27 AM There is apparently some sort of "predefined" order that is imposed by the IDE. I have found that if you re-arrange your toolbars so that the addition of the debug toolbars doesn't move yours, they will stay put. This makes me think that the programmers decided that to optimize window space when they are all open, toolbar X should appear next to toolbar Y. As for the "VC6" behavior, I thought I read that .NET was supposed to be quite a bit better at that than VC6. Can't remember where, though.
thruska	Posted - Aug 30 2006 : 5:13:12 PM Actually, I have a product on my website (XLAuditor) that is a COM add-in for Excel. Office apparently doesn't remember the positions of COM add-ins and I've had a few requests to fix it (just haven't had the time to update the add-in). Office exposes barely enough functionality to "sort of" remember toolbar positions. I suspect the VS.NET IDE has the same problem: Depend on the add-in programmer to remember where add-in toolbar positions are in the IDE instead of letting the IDE do it for the programmer. I suppose the argument goes that the person might uninstall the application between runs of the IDE/Office/whatever and that would mess up the toolbars or the add-in might fail to load...but I fail to see the logic in either option. The more logical explanation is: Some programmer at Microsoft was feeling incredibly lazy and we suffer as a result.
kevinsikes	Posted - Aug 30 2006 : 3:11:44 PM Isn't this a function of the IDE, rather than any particular add-in whose commands may be exposed through a toolbar? And speaking of this issue, can anyone help me find a way to get back to the VC++ 6.0 behavior of displaying different toolbars in edit mode vs. debug mode? It was very elegant in VC6: right-click the toolbar area in edit mode, check the toolbars you want; run the debugger, check the toolbars you want while debugging, and the IDE persists each mode's configuration. For instance, I want to get rid of the build toolbar to make room for the debug toolbar. VS.NET 2003 doesn't appear to persist these configurations properly.

Snitz Forums 2000