| Author |
 Topic  |
|
|
thruska
Ketchup Master
71 Posts |
 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.
|
Thomas Hruska
CubicleSoft President
http://www.cubiclesoft.com/ |
|
|
kevinsikes
Tomato Guru
USA
271 Posts |
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. |
Kevin Sikes
Infotainment Platform Design Engineer
Ford Motor Company |
 |
|
|
thruska
Ketchup Master
71 Posts |
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.
|
Thomas Hruska
CubicleSoft President
http://www.cubiclesoft.com/ |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
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. |
Joe Pizzi |
|
|
|
kevinsikes
Tomato Guru
USA
271 Posts |
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. |
Kevin Sikes
Infotainment Platform Design Engineer
Ford Motor Company |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
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  |
Joe Pizzi |
|
|
|
kevinsikes
Tomato Guru
USA
271 Posts |
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 SubThe 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!) |
Kevin Sikes
Infotainment Platform Design Engineer
Ford Motor Company |
|
|
| |
Topic |
|
VAX toolbar and debugging
