[Lazarus] TTabControl (d)evolution

[Hans-Peter Diettrich]

Felipe Monteiro de Carvalho schrieb:
> On Tue, Aug 2, 2011 at 11:29 PM, Hans-Peter Diettrich
> <DrDiettrich1 at aol.com> 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