Quote Originally Posted by 7edm View Post
Any special reason to .Move the containers out of view rater than just setting its .Visible property, speed, flicker etc.?
Yes.

1) Backward compatibility with existing code that used the original SSTab (and stored properties).

2) Not to mess with the Visible property, that the programmer could have used (or want to use) to show/hide controls. I think that must have been the reason why the original developers of the SStab did that way.
When the host program changes the .Left of a control that is hidden (shifted to the left), the SSTabEx has implemented a way to place it in the right tab anyway. In case of controls that are windows and thus can be subclassed, that is done at the moment, in case of windowless controls, they are handled when the tab changes (it is not possible to know that a label changed place, perhaps only executing a lot of code on every form paint, but that doesn't seem something reasonable to do).
In sum: the SSTabEx has better handling than the SSTab regarding the host program changing control's Left. But still, not perfect.

3) A solution could have been to put the controls into a container, for example a picturebox or a frame, but it is not possible to change the container of a contained control in an UserControl from a container of the host program to one of the component program. I tried, it raises an error.

Any suggestion can be considered, now I don't have an alternative.

Note: Now I remember that I saw some tab control that said it used containers to hide the controls, but I don't remember now where it was. I think it was some old commercial control. Perhaps it worked only with windowed controls and set the parent with the SetParent API.

About your resizer program, test for the TypeName of the control's container, and when it is "SSTabEx", then use ctl.Container.ContainedControlLeft(ctl.Left) instead of ctl.Left. (Add the code, it is on post #47, but you need to be using the latest version)

Did you have code in the resizer to handle the SSTab? How?

About the routine with GoTo Exit_Function that you quoted, it surely won't win any beauty contest, but I don't see a functional problem with it.
If I had made it from the start, surely I would had made it as you suggested, but when I had the control already written and working, I realized that I was leaving the Err object with some errors set in some parts. It wouldn't be a problem most of the times, but I thought better not to leave them because when the control is used in source code, the host program shares the same Err object, and if the host program is checking for errors, it could lead to a false positive.
Then I looked for the places where Exit Sub/Function's where inside an error handling and quicky changed them to GoTo Exit_Sub/Function, added that label, and cleared the Err object at the end before exiting. Without having to resort to adding flags and more code.
That specific case that you quoted could have been resolved without adding a flag, but I replaced all the same way without studing each one in detail.

About picking up bad habits, yes, if you can't control yourself or you are a beginner then you better abide by the rules and never break any.
I know it is not only about beginners, but I don't want to start a war (many here will agree with your view).
They are all good rules, I encourage to follow them... the 99% of the times.

When I code, I am very focused on what I'm doing and don't want to add the burden of "someone won't like it". I'm not saying I don't care or I don't consider that, but I don't like to spend much time on these things.
Anyway I read objections, and I can change things when someone express reasons that I see valid.