.comment-link {margin-left:.6em;}

I Hate Linux

Tuesday, December 11, 2007

Proof of concept add-in: Tab Management

Part of the reason I created Tab Scroller was that at times I just have too many tabs to deal with in the Windows Home Server Console and today I came up with another method of dealing with large numbers of them... a Tab Management tab.

What does it do? It is a tab itself, which in turn loads a specified group of add-ins itself instead of having the Home Server Console do so (via renaming of the files) and then displaying the appropriate control when the desired one is selected from the presented list box:

Tab Management Test

The amazing thing about this add-in... is that it doesn't do any crazy hacks the way Tab Reorderer or Tab Scroller do.

Unfortunately this add-in is just a proof of concept test right now and is not something I'm likely to release anytime soon... largely because I can't decide on a good way to display the settings in the Settings dialog (something I am responsible for in order to make the main form work the way it does).

I figure though that this will be a good place to add the functionality of Tab Reorderer and Tab Scroller in once it does see the light of day and users.

Labels: ,

5 Comments:

  • Brendan, refer to my comment http://mswhs.com/add-in-list/#comment-3563
    The idea was to have a "desktop" of add-ins, grouped by functionality, and for sentimental reasons having the look and feel of windows 3.x programme manager. It could be called add-in manager. You are close!!!

    By Anonymous trebmal, at 12:04 AM  

  • Brendan

    Having taken up the gauntlet to get something like this functional, was wondering if you were open to a quick brain dump around an issue I'm facing.

    I have come to the same conclusion that you have, that you need to rename the DLL inorder to prevent the Home Server Console initialization from loading the DLL. Then reflect the Add-In DLL and add the TabControl into a Panel placeholder on a central Tab.

    This is all fine and dandy, however hit the issue that if a developer also codes in a SettingsExtender this functionality will be lost if I rename the DLL.

    At present the only way round it I can see is to document that Developers wanting to be compatible have to split out TabExtenders and SettingsExtenders into seperate assemblies. Am I missing something here. Is there a way I can manually load SettingsExtender into the Settings dialog after the Console has Initialized?

    Cheers

    Simon

    By Anonymous Sj, at 7:54 PM  

  • You are absolutely right in your figuring out how such an add-in would work... and it’s the settings issue which has kept me from having a releasable version of this add-in.

    Currently I'm leaning towards a settings page that acts just like the main view... with a list of settings tabs inside of a larger parent add-in.

    As for manually loading settings tabs into the Settings dialog... it is possible, and far easier than doing so to the main view (although both are pretty hackish) as the visible list of tabs in settings is ultimately just a ListView instead of a strange custom (TabContainer) control on the main form.

    By Blogger Brendan, at 5:29 AM  

  • Brendan

    How are you actually getting to the Settings Dialog ListView control? Any .Parent properties appear to be null when I try to crawl through the OM.

    And I had the same idea, just offer a drop down of any SettingsExtender that are found within the same assemblies as a ConsoleTabExtender. And just display a warning to the user when they first load the Add-In Manager that Settings links may not work properly. Not the most ideal solution :)

    By Anonymous sj, at 11:25 AM  

  • Found it, not too much of a hack. Just traversing back up the .Parent OM Model from the Add-In Manager Settings Dialogue Control

    Cheers

    Simon

    By Anonymous sj, at 4:03 PM  

Post a Comment

<< Home