[Lazarus] TTabControl (d)evolution

[Hans-Peter Diettrich]

Felipe Monteiro de Carvalho schrieb:
> Ok,
> 
> Now I see that it works like this:
> 
> TTabControl (TCustomControl)
> -> TCustomTabControl
> -> other client controls
> 
> TCustomTabControl has the lowest Z-order, so it is always bellow other controls.

Ah, then it may be necessary to restrict the background painting and 
putting other controls into the DisplayRect, instead of the ClientRect 
of the TTabControl.

BTW the Win32 widgetset already implements an according ClientRect, that 
excludes the tabs. AutoSize can be implemented easily, by adjusting
  tabctrl.Height := tabctrl.Height - tabctrl.ClientHeight
but this does not work yet with other widgetsets.


> So, it works fine except for two issues:
> 
> 1> It has a wrong class hierarchy
> 2> Tabs.Objects doesn't work
> 
> One thing however. The Delphi docs don't say that Tabs.Objects should
> contain a list of all objects visible for a given tab.

Right, Tabs.Objects[] is unused in the control itself, child controls 
are stored in Controls[], as usual. Nonetheless Delphi allows to store 
components in Objects[], so that it were a nice place to hold the 
(visible) pages, as I could verify with a test program (see 
TNewTabControl.DoChange). Then a TPageControl would become only a 
special case of a tabbed control, with the page control types restricted 
to TTabSheets/TCustomPage. The other use were for notebook docking, 
where the docked clients can be stored in Objects[], with automatic 
switching by clicking the tabs.

As for the implementation of the Tabs.Objects[], I based the Tabs[] of 
TNewTabControl on TStringList, instead of TStrings, so that 
Tabs.Objects[] is available immediately. Only the notifications for Add 
and Delete from Tabs[] have to be added to that class. The 
TCustomTabControl.FAccess is a general TStrings, compatible also with a 
TStringList (see the various constructors).

DoDi