Gradient Tabbed Dialog

• What it doesn't have:
  • A quick note before going on... This control does not support multiple rows of tabs or a scrollbar when there are too many tabs to show on one line. Both multiple rows of tabs and scrollbars promote misuse of tabbed dialogs.. this is stated repeatedly on the site below (I bent the rules slightly with the scrollbar)
  • The current version supports tabs on top only. Interface Hall of Shame Tabbed Dialogs - This link is subject to frequent change (arghhh). If broken, click here and hit the Search button, if interested.
     
• What it does have:
  • Now, a bit about what it does have. Click here to see a few screen prints.

• Colors
  • For a long time, people in the groups have asked for a tabbed dialog that supports colored backgrounds.. well, here you go . Separate Fore/Gradient/Back colors for each tab and another for the control's background (background's the only one the SSTab has) The current version supports 4 blend colors for each gradient.
     
• Containers
  • First a little background on "the other guys" controls.
     

• The TabStrip Control
  • Ok... anyone that has experience with the TabStrip control, knows that this is not a container control. This means that you place all controls in frames (or other containers), move them into place and set them visible or topmost when the corresponding tab is clicked. This confuses a lot of people when they first attempt to use the control (including me... way back when). Once you get used to it though... and come up with fancy ways to manipulate what shows where, it's a trustworthy, trouble free control.

• The SSTab control
  • The SSTab control, on the other hand, is a container control. This means that you can drop your controls on one tab, switch to another tab and drop more controls... This is very cool but, one important fact isn't obvious enough to most..... The SSTab control... no matter how many tabs you have.. is all one container. When you switch tabs, all controls that are currently showing are moved 75000 twips to the left... which obviously removes them from view. The controls that belong on the tab you're now switching to are moved 75000 twips to the right, which brings them into view. This is all fine and dandy.. and has been around for years, but it has it's problems.

• Dynamically resizing controls.
  • The most frequent problem I've seen in the groups comes from attempting to dynamically resize controls on your form as the form size changes. It all seems easy enough until you remember that the SSTab has internal variables that keep track of each control's position.. when you move controls around that are contained by an SSTab control, it loses track of where the control should be. This means that you get controls that show on the wrong tab... or not at all. The work around I came up with involves.... you guessed it.. placing only a single frame on each tab and all controls in those frames. When a tab is clicked, move the tab into position using code... what this does is take all control away from the SSTab and gives it back to you.. at the same time, people may say, it takes away some of the apparent ease of working with this control (compared to the TabStrip control, which forces you to manipulate control visibility)
     
• Adding controls to tabs at runtime.
  • This one comes up a lot in the groups. Because of the way that the SSTab works (moves controls left and right without telling you), adding controls at runtime can be painful.. they'll show up on the wrong tab.. or not at all. The work around for this is to switch to the tab you want the control to be displayed on and then create the control. While this works, it's not what people expect. The safest way to add controls to the tabs at runtime is to... not do it at all.. If you started by placing only a single container (frame) on each tab and those frames contain the controls that show on each tab, add controls to the frame at runtime.. solves that problem very nicely because the tab control isn't aware and doesn't care that the frame now has an additional control in it.. this also takes care of any positioning problem because the controls position will be relative to the upper left of the frame instead of any +/- 75000 twip coordinates that the tab control may be using.

• Option Button Behavior.
  • This problem doesn't come up very often... but it's still something to keep in mind. Option Buttons allow only one element of their group to be set True at any time. An Option Button group is... 2 or more Option Button controls that share the same container.. Well... Since the SSTab is only one container (no matter how many tabs), you'll find that Option Buttons that are placed directly on separate tabs will have an unexpected behavior.. That is, since only one can be True, setting an Option Button on one tab will clear all others placed on any of the other tabs (if they're directly on the tab). Of course, broken record here.. but, the work around is, again, start by placing a single frame on each tab.. then fill that frame with the controls that belong on that tab. That takes care of that.

• The TBGDialogCTL Control.
  • This control is a bit different from the controls above. At design time, it functions very similar to the SSTab. When you click a different tab, all controls are moved out of, and then into view, just like the SSTab. At runtime though, all controls placed on the tabs are moved into a separate frame. And, you guessed it, each tab gets it's own frame. This means that all control resizing problems go away because there's no more moving +/- 75000, while running, all controls on the tab should report Top/Left as if they were all on the current tab. Also, the seemingly strange Option Button behavior goes away because Option Buttons on other tabs are in different containers (at run time), and any dynamic control addition problems go away by using the methods provided.

• Unique Navigation methods.
  • This is where I may've stretched the scroll bar rules a bit. (see image below)
    Notice the context menu and small "Nav" buttons.
  • The Nav buttons show in the lower left and lower right corners of the control and let the user know how many tabs there are to the right and left of the current tab. They can be set to either show all tabs, show only visible tabs or hidden.
  • Same goes for the Context Menu. This menu fires an event before showing. This allows you to cancel it if desired (in case you want to show your own menu in its place). It's visible states are Show All and Show All Visible. There's no Hidden state for the menu because you can suppress it in the event handler.

• A) In the picture below, the tabs are shown in the order shown on the context menu.
   
• B) The context menu captions reflect the current tab captions.
   
• C) Hovering over a Nav button shows that tabs TabTip.

Click here to download a fully functional trial version that Runs Only in the VB IDE
Important Note : Downloads are temporarily disabled for this control!!! Contact me for more information.

Note: There's a new property called "ControlScan" that, when set = False, won't check for new controls at runtime. This speeds up overall performance considerably. Be sure ControlScan is set = True if you plan to load controls at runtime and place them on the tabs.