[Lazarus] TTabControl (d)evolution

[Felipe Monteiro de Carvalho]

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.

But even if this works, TNewTabControl still lacks a designer, and I
am not sure how one could design it. The pages will occupy all the
client area, so it won't be possible to drop controls. Maybe one would
need to create a new Sheet class for it and set it as invisible in the
designer?

This change seams correct in any case so I commited in rev 31849 the
change to ChildClassAllowed and I ifdefed TNewTabControl with {$ifdef
LCL_NEW_TABCONTROL} and added a registration for it so that you can
set this define and test designing.

> More properties are missing, at least from the Win32 widgetset. The problem
> is that in the current implementation all properties are passed to the
> widgetsets in TCustomPage parameters, so that this class must be extended
> with all currently unhandled properties, or dedicated methods have to be
> added to TWSCustomTabControl. This can be done later, once we know how to
> make TTabControl work at all, with all widgetsets.

It should not be a problem for TTabControl to have sheets if they are
invisible in the designer and if you can drop components directly
inside the main component. The existence of sheets seams to be
indispensable for gtk for example, but they can be hidden enough so
that they don't interfere with the expected usage of the control.

-- 
Felipe Monteiro de Carvalho