Background
I'm not much of Add-In user, but my liking for a tabbed interface of open code windows has meant that CodeHelp has been a permanent fixture of my IDE for a few years now. Just recently, I thought I'd develop an Add-In of my own, and wondered if I could improve on the CodeHelp offering. Whether I have or not, will be a matter of personal opinion, as I only focussed on the things that I wanted to change, without regard for any features that I, personally, do not use.
Things I like about CodeHelp's tabstrip:
1) It's always available, whether in Design, Run or Break mode
2) You can re-order the tabs to your liking (although it's a bit clunky-feeling)
Things I don't like:
1) It has lots of sub-classing and hooking, which gives me stability concerns
2) You can't close a tab without activating it first
3) You can't re-order the tabs without first activating the tab you are moving
4) Sometimes the active tab gets out of sync with the active code pane
About my Tab-Strip
I tried, of course, to retain everything from my 'positive' list, whilst eliminating those that (to me) are negatives. I suspect that other users may have quite different lists, such as keyboard shortcut access, and so on. If so, I'd like to hear from you in the replies. Maybe I can then incorporate those features. Or maybe you can modify the code as you see fit...
Anyway, this add-in, as the title says, can be used in both MDI and SDI modes, and contains no sub-classing or hooking. Instead, it uses a simple polling mechanism which does two tests, every 125ms, essentially asking:
1) Has the active window changed?
2) Has the number of IDE windows changed?
If either of those is true, things get taken a step further and all of the windows are enumerated, and the tab-strip is updated if there are any recently-closed or newly-opened code/designers windows. All-in-all, this should be pretty IDE-safe, and is actually less process-intensive than testing Window messages as they come by. It is only a tab-strip after all, and just doesn't require the level of 'state-awareness' that hooking/sub-classing might afford.
So, here it is:
Image may be NSFW.
Clik here to view.
What Else?
I have commented out all the logging code, but if you need/want to turn this on, there is a hidden listbox in frmTabStripOptions (just resize the form to see it)
Oh, yes, the UserControl is perfectly re-usable outside of this Add-In, if you like it and want such a thing.
Known Issues
MDI Only
None, yet, but I'm sure somebody will find one!
SDI Only
Window captions for Forms are not in the format 'Project - Component' but, instead, show the caption property for the form. As such, any caption re-naming is not picked up as part of the polling process. This could be addressed, but just doesn't seem worthwhile, at least not to me.
Both
Because the Tab-Strip is hosted by a regular Office toolbar, it is possible to drop another toolbar on top of it. Not sure anything can be done to prevent this behaviour.
When pressing F5, all designer windows are immediately closed (normal behaviour), but the same is not true (at least not consistently) for the Object Browser, which seems to sometimes remain open and sometimes get closed. As such, the tabstrip might occasionally show a tab for a non-existent Object Browser window, depending on when the IDE chooses to destroy it (if at all), and whether or not it was the active window when F5 was pressed.
To Do
I'm not much of Add-In user, but my liking for a tabbed interface of open code windows has meant that CodeHelp has been a permanent fixture of my IDE for a few years now. Just recently, I thought I'd develop an Add-In of my own, and wondered if I could improve on the CodeHelp offering. Whether I have or not, will be a matter of personal opinion, as I only focussed on the things that I wanted to change, without regard for any features that I, personally, do not use.
Things I like about CodeHelp's tabstrip:
1) It's always available, whether in Design, Run or Break mode
2) You can re-order the tabs to your liking (although it's a bit clunky-feeling)
Things I don't like:
1) It has lots of sub-classing and hooking, which gives me stability concerns
2) You can't close a tab without activating it first
3) You can't re-order the tabs without first activating the tab you are moving
4) Sometimes the active tab gets out of sync with the active code pane
About my Tab-Strip
I tried, of course, to retain everything from my 'positive' list, whilst eliminating those that (to me) are negatives. I suspect that other users may have quite different lists, such as keyboard shortcut access, and so on. If so, I'd like to hear from you in the replies. Maybe I can then incorporate those features. Or maybe you can modify the code as you see fit...
Anyway, this add-in, as the title says, can be used in both MDI and SDI modes, and contains no sub-classing or hooking. Instead, it uses a simple polling mechanism which does two tests, every 125ms, essentially asking:
1) Has the active window changed?
2) Has the number of IDE windows changed?
If either of those is true, things get taken a step further and all of the windows are enumerated, and the tab-strip is updated if there are any recently-closed or newly-opened code/designers windows. All-in-all, this should be pretty IDE-safe, and is actually less process-intensive than testing Window messages as they come by. It is only a tab-strip after all, and just doesn't require the level of 'state-awareness' that hooking/sub-classing might afford.
So, here it is:
Image may be NSFW.
Clik here to view.
What Else?
I have commented out all the logging code, but if you need/want to turn this on, there is a hidden listbox in frmTabStripOptions (just resize the form to see it)
Oh, yes, the UserControl is perfectly re-usable outside of this Add-In, if you like it and want such a thing.
Known Issues
MDI Only
None, yet, but I'm sure somebody will find one!
SDI Only
Window captions for Forms are not in the format 'Project - Component' but, instead, show the caption property for the form. As such, any caption re-naming is not picked up as part of the polling process. This could be addressed, but just doesn't seem worthwhile, at least not to me.
Both
Because the Tab-Strip is hosted by a regular Office toolbar, it is possible to drop another toolbar on top of it. Not sure anything can be done to prevent this behaviour.
When pressing F5, all designer windows are immediately closed (normal behaviour), but the same is not true (at least not consistently) for the Object Browser, which seems to sometimes remain open and sometimes get closed. As such, the tabstrip might occasionally show a tab for a non-existent Object Browser window, depending on when the IDE chooses to destroy it (if at all), and whether or not it was the active window when F5 was pressed.
To Do
- Add those little scrolling buttons to the ends of the tabstrip. For now you can Ctrl-drag the whole tabstrip to do the same job.
- Add some options (font size, right-click behaviour, etc.) I feel that there's potential for such 'click-behaviour' options to apply more to SDI layouts, for some reason (e.g. right-click a tab to maxmize). But maybe that's just me finding SDI a bit chaotic!
- Add a 'Max tab width' option, as suggested in Post #2
- Options to close multiple tabs in one operation, as suggested in Post #2