Thanks for the attempt to replace the old TTabControl by the new implementation :-)
There seem to exist some issues with the new implementation, so that I'll give some background information, about the new TCustomTabControl and descendants.
The basic TCustomTabControl does not have pages any more, these are added only in derived controls (TPageControl). Instead any kind of controls can be shown with a tab, as implemented in TTabControl. While tabs can be added at design time to a TTabControl, associated controls (currently) have to be assigned at runtime, to
tabctl.Tabs.Objects[tabindex]. These controls can have any parent, and can be used for any purpose. The current TTabControl default is to show an associated control when a tab is selected, and to hide all other associated controls, so that the behaviour is very close to a TPageControl. This behaviour can be overriden by an OnChange handler, and should be made optional by a property (e.g. ShowPages) in the next version.
A TPageControl only adds support for constructing and adding pages at designtime, and allows to hide single tabs programmatically. Docking features are not really new in the TPageControl, the EasyDockManager already uses something like a TTabControl internally, for notebook docking.
Unfortunately the widgetset interface uses TCustomPage parameters to transfer arguments to the widgetsets. I don't understand why the widgetsets have to bother with pages at all, when associated controls can be shown without any special widgetset support, as demonstrated in the new TTabControl (see above). All these problems would disappear, when the support for associated pages would be removed from the widgetset interface. At least the Win32 native tabbed control has no idea of associated pages, so that all support for pages can (and should) be implemented in TPageControl.
But as long as the interface is as it currently is, we'll have to live with all the page-related problems. All widgetsets have to distinguish between basic unpaged controls (TCustomTabControl) paged controls (TPageControl). For that distinction a property IsUnpaged has been added to the TCustomTabControl. When IsUnpaged is True, a widgetset should *never* try to treat an TCustomPage parameter as a visible control, instead it only should read the properties of that control, as required. E.g. the text of an tab can be retrieved from page.Caption.
The new TCustomTabControl has been implemented and tested *only* with the Win32 widgetset, because I don't know about implementation details of other widgetsets. When an AV occurs in an widgetset, due to improper use of an TCustomPage parameter, the related code should be skipped when tabctrl.IsUnpaged is True.
It also may be a good idea to move the ChildClassAllowed method from TCustomTabControl into TPageControl, because the basic control is not restricted to TTabSheet descendants for its child controls.
For now I'd suggest to restore the TTabControl to its prior version, before SVN 31782, and to successively fix the other (non-Win32) widgetsets.
In the long run I'd suggest to simplify the widgetset interface, by removing all page related functionality from it, and replacing the TCustomPage parameters by the really required information, e.g. by an string for the tab title in AddPage. For the implementation of the TPageControl functionality its perfectly sufficient, when every widgetset can add (remove...) tabs, and can report the size of its client area. The implementation of hidden pages, with the consequently required mapping between tab and page indices, as well as the handling of the visibility of the currently seleced/unselected page, can be implemented easier in the TPageControl, independent from any widgetset.
DoDi
