SSTab, are you crazy?

[ChrisE]

Hello Eduardo,

I wonder how does people do at design time with TabStrip in cases, for example:

A form that is almost the size of your current developing screen.
You have a TabStrip of, let's say 6 tabs, but may be less that occupies almost all form's size.

How do you manage to place all those Frames or PictureBoxes that are containers of each tab of the TabStrip on the form?

to design your form with Tabstrip look at the Form_load code, there you give the size of the Tabstrip and then
the size of the Frame.



where is the problem ?

regards
chris

[ChrisE]

here a example

just put Frame 2,3 and 4 to the bottom of the form make them as small as a Textbox.

take Frame 1 and set the height to 5900 , set the widht to 7400
this is the designspace !
place you textboxes, Labels, Pictureboxes where you want them
now run the program.
everything looks Ok, make Frame 1 as small as a Textbox, put it at the bottom left.

no do the same with Frame 2
etc...

regards
Chris

[wqweto]

I prefer the SSTab.
Reasons:
1) Less code to set up.

How do you deal with tabbing anomalies `SSTab` introduces? e.g. when you have two `TextBox`es on first and second tab of an `SSTab` control the end-user is able to navigate with {Tab} key to the currently invisible `TextBox`!

The reason for this unfortunate behavior is that on tabclick `SSTab` control only moves contained controls in and out of sight (left to right and back), w/o setting visibility or WS_DISABLE flag.

The most common (and best) way to deal with this problem is to place a single `PictureBox` for each tab (or just a control array of `PictureBox`es) and show/hide these second "manual" containers on tabclick.

Provided that you already need to use `PictureBox` containers to fix `SSTab` problems, including handling `picTab` visibility through code, it's just a single step forward to just ditch `SSTab` in favor of a (themed) `TabStrip` control.

When designing forms with `TabStrip` and `PictureBox`es for each tab, `Ctrl+J` shortcut (Bring to front) comes very handy -- just select tab's `PictureBox` from the combobox in `Properties` windows and bring it up.

cheers,
</wqw>

[Elroy]

How do you deal with tabbing anomalies `SSTab` introduces? e.g. when you have two `TextBox`es on first and second tab of an `SSTab` control the end-user is able to navigate with {Tab} key to the currently invisible `TextBox`!

The reason for this unfortunate behavior is that on tabclick `SSTab` control only moves contained controls in and out of sight (left to right and back), w/o setting visibility or WS_DISABLE flag.

The most common (and best) way to deal with this problem is to place a single `PictureBox` for each tab (or just a control array of `PictureBox`es) and show/hide these second "manual" containers on tabclick.

Hi wqweto. Take a look at my post #24. I've used that class with the SSTab control for years, and it makes it bullet-proof as far as I can tell (with no need for PictureBoxes). In addition to tabbing, there's also a bit of a problem with ComboBoxes, which is also corrected by that class (see comments in class code). I'll also edit that post to give a brief example of how I use the class.

Take Best Care,
Elroy

[Eduardo-]

Hello Eduardo,



to design your form with Tabstrip look at the Form_load code, there you give the size of the Tabstrip and then
the size of the Frame.



where is the problem ?

regards
chris

Problem? Did you know that there is something called "design time"?

[Eduardo-]

How do you deal with tabbing anomalies `SSTab` introduces? e.g. when you have two `TextBox`es on first and second tab of an `SSTab` control the end-user is able to navigate with {Tab} key to the currently invisible `TextBox`!

The reason for this unfortunate behavior is that on tabclick `SSTab` control only moves contained controls in and out of sight (left to right and back), w/o setting visibility or WS_DISABLE flag.

I don't deal with it.
I just set all the tabindexes in order and if the user wants to navigate with tabs, he will have to click on the first control every time he changes the tab.
In my life I never knew of any user who uses tabs to navigate (I do from time to time press the tab key to move to other control).
I also put all the caption's accelerators, another feature that perhaps is never used.

The most common (and best) way to deal with this problem is to place a single `PictureBox` for each tab (or just a control array of `PictureBox`es) and show/hide these second "manual" containers on tabclick.

Many times (not always) I put a borderless picturebox on each tab as a container, mostly because if later I want to add a new tab between other existent tabs, it is easier this way.

Provided that you already need to use `PictureBox` containers to fix `SSTab` problems, including handling `picTab` visibility through code, it's just a single step forward to just ditch `SSTab` in favor of a (themed) `TabStrip` control.

When designing forms with `TabStrip` and `PictureBox`es for each tab, `Ctrl+J` shortcut (Bring to front) comes very handy -- just select tab's `PictureBox` from the combobox in `Properties` windows and bring it up.

cheers,
</wqw>

No. With SSTabs you can have the controls contained on each tab at design time, that's the main feature that you don't have with TabStrip.

[wqweto]

Hi wqweto. Take a look at my post #24. I've used that class with the SSTab control for years, and it makes it bullet-proof as far as I can tell (with no need for PictureBoxes). In addition to tabbing, there's also a bit of a problem with ComboBoxes, which is also corrected by that class (see comments in class code). I'll also edit that post to give a brief example of how I use the class.

Take Best Care,
Elroy

There is no problem with `ComboBox`es when using separate container-per-tab strategy -- at least in a simple test I did here (I've not been using `SSTab` for quite some years now).

But both `SSTab` and `TabStrip` controls are distinctively missing focus-first-visible-child functionality. It's pretty useless for a tab control to remain focused on tabclick (or Ctrl+Tab/F6 tab switch) IMO.

cheers,
</wqw>

[wqweto]

I don't deal with it.
[big snip]
No. With SSTabs you can have the controls contained on each tab at design time, that's the main feature that you don't have with TabStrip.

I see you point. Unfortunately this does not work for me or any other professional, because we can't be bothered to use `SSTab` control only because it's easier for us devs to implement it and in the processes end up with a solution that makes our end-users lives miserable.

cheers,
</wqw>

[Eduardo-]

I see you point. Unfortunately this does not work for me or any other professional, because we can't be bothered to use `SSTab` control only because it's easier for us devs to implement it and in the processes end up with a solution that makes our end-users lives miserable.

cheers,
</wqw>

Nobody makes the end user's life miserable. If you din't read the first time, I'll repeat: they don't use tabs to navigate.

I have to say that I'm not talking about data entry screens, I use tabbed controls mainly on to scenarios:

1) For configuration screens.
2) To show information ordered by subject.

In the fist case the end user usually needs to click in the field that he wants to change.
In the second case they usually only need to read.

Of couse, I'm not saying that it is not desirable at all to have that fixed, but it's almost unimportant since nobody will note it.

If the forms were data entry screens, in that case I agree that the feature is relevant.

[Elroy]

Well, I shouldn't jump in, but it's Friday and I'm coasting a bit, so I will.

I use the SSTab for data entry screens all over the place, and I love them and my users do too. I'm bewildered as to what the problem is.

Wqweto, I like much of the code you've written around here, but we've got to agree to disagree on this one.

I see you point. Unfortunately this does not work for me or any other professional, because we can't be bothered to use `SSTab` control only because it's easier for us devs to implement it and in the processes end up with a solution that makes our end-users lives miserable.

If we push those thoughts to their logical conclusion, we may as well return to using Notepad-type code editors because they allow us maximum flexibility to write the best code for our users. Also, I'm not sure that making things easier for coders and making them easier for users is an antithetical tension. I will agree that that's true in some cases. For me, the idea of bound controls comes to mind, which I can't stand (although I suspect there are those who will even disagree what that).

However, ideally, ease for the coder and easy/intuitive programs for the users can rise in a mutually beneficial way. I certainly believe that the ability to design forms via select-and-draw from the ToolBox is an example of this. I'd hate to think that I'd have to write all of my form-design code in notepad.

For me, a tabbed dialog that's WYSIWYG at design time is a natural extension of this.

People may point out that the SSTab can't be themed, and is looking somewhat dated, but those aren't concerns to me. For my application, I'm much more concerned with user functionality and ease of design. And the SSTab provides both of these in spades (IMHO).

To All, Have a Great Weekend,
Elroy

[Schmidt]

FWIW, I've just finished a replacement of the SSTab - still with a few rough edges I guess, but it should work
as a direct replacement for the most common use-cases (feel free to enhance it ... + a post-back of your changes into the
code-bank thread here: http://www.vbforums.com/showthread.p...-and-VB-Frame)
would be nice...



Olaf

[wqweto]

Wqweto, I like much of the code you've written around here, but we've got to agree to disagree on this one.

Hey, it's ok to like my code and disagree on my oppinions in random threads :-))

But do you take care of keyb tabbing in your SSTab-ed forms? Do you fix tab order when you move controls around at design-time?

Not doing the first one and not caring about the second one makes end-users lives miserable. Both of these can be impl w/ SSTab control per se with some additional code and some attention to detail on devs part. Certainly not doing it would be easier for us but this can't be the only reason one uses SSTab control -- ease of use for *developers*. . .

cheers,
</wqw>

[Elroy]

Hi wqwewto,

But do you take care of keyb tabbing in your SSTab-ed forms?

Absolutely, to the first question. That's what that class is all about in post #24. Regarding your second

Do you fix tab order when you move controls around at design-time?

Nope, but I'm not sure anything does that. That doesn't happen even if you're not using any containers at all. In some ways, that harks back to this thread, and a specific case where I designed a complex form and didn't want to mess with the TabIndexes.

You have a GREAT day,
Elroy

[Eduardo-]

Nope, but I'm not sure anything does that. That doesn't happen even if you're not using any containers at all.

If you move a control, let's say from the top of the form (or the top of a SSTab tab) to the bottom, the TabIndex property of the control doesn't change, so when the design of the form is finished, the developer should put the proper values for every TabIndex of every control.

Also if you add accelerators to the labels, every label should have a tabindex with value of the control that will access -1.

[Eduardo-]

FWIW, I've just finished a replacement of the SSTab - still with a few rough edges I guess, but it should work
as a direct replacement for the most common use-cases (feel free to enhance it ... + a post-back of your changes into the
code-bank thread here: http://www.vbforums.com/showthread.p...-and-VB-Frame)
would be nice...



Olaf

Thank you very much Olaf.
Now I'm away from home and don't have VB6 here, I'll test it next week when I'm back.

PS: I guess that "Tab" was a reserved VB6 keyboard because you needed to change it to SetTabIdx.
Just an idea: Could it accept that keyword as a property name using a typelib?

[Krool]

PS: I guess that "Tab" was a reserved VB6 keyboard because you needed to change it to SetTabIdx.
Just an idea: Could it accept that keyword as a property name using a typelib?

Even if, it is always bad to expose a typelib publicly as then when you ship the app you also always need to ship the typelib as well.

[Eduardo-]

Even if, it is always bad to expose a typelib publicly as then when you ship the app you also always need to ship the typelib as well.

I thought the typelibs were only needed with the source code.
Am I wrong?

[Krool]

I thought the typelibs were only needed with the source code.
Am I wrong?

I think for UserControl in Std-EXE it does not matter. But in a OCX for sure, if the type lib is exposed to "outside" it needs to be referenced by the end-user.