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