Felipe Monteiro de Carvalho schrieb:
On Tue, Aug 2, 2011 at 11:29 PM, Hans-Peter Diettrich
<[email protected]> wrote:
I just tested a raw TCustomTabControl, and it worked immediately as a
TTabControl with the Win32 widgetset. After moving ChildClassAllowed into
TPageControl, it allows to add components of any type to its client area. If
you can verify this for the other widgetsets[1], the whole implementation of
TTabControl reduces to the handling (almost publishing) of the properties.
I am amazed that this worked in Carbon and in Qt, although I still
have to test the much less reliable Gtk.
The good news: adding components at design time works immediately, when
csAcceptControls is included.
However the internal handling of the pages, created for every added tab,
seems to move the pages on top of the Z-order, hiding or invalidating
most of the child controls. E.g. a StatusBar can be added to a
TCustomTabControl, but will not show any content when tabs are added
later. An unaligned button disappears completely :-(
In my former attempt I introduced IsUnpaged, so that the control and
widgetsets can know whether the pages (in fPageList) should ever be
shown. This turned out to be problematic to implement, in detail with
the gtk2 widgetset. So I'll try now to create a dummy page for every
tab, but exclude all code from TCustomTabControl that tries to make
these pages visible when IsUnpaged=True. When this works with the Win32
widgetset, we can test it with the other widgetsets.
In the long term I still suggest to remove *all* code from the
widgetsets, that deals with the TCustomPage parameters as *visual*
components, and switch the pages of a TPageControl outside the
widgetsets, by simply switching their Visibility accordingly.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
