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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
