[Lazarus] TTabControl (d)evolution

[Hans-Peter Diettrich]

Felipe Monteiro de Carvalho schrieb:
> On Wed, Aug 3, 2011 at 7:44 AM, Felipe Monteiro de Carvalho
> <felipemonteiro.carvalho at gmail.com> wrote:
>> I am amazed that this worked in Carbon and in Qt, although I still
>> have to test the much less reliable Gtk.
> 
> No, it doesn't work in Gtk2.
> 
> The button is never shown.

See my thoughts about moving the page widgets out of view. Something 
like the dummy page could be used as a persistent client area. If 
nothing helps, the gtk widget can be constructed from two independent 
tabs and client widgets, internally.


>> 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.
> 
> I don't see this with good eyes. Yet another class hierarchy
> difference? It would be better if we do things 100% correct this time.

The class hierarchy is not affected. Actually every descendant uses its 
own class for FAccess, it can be any TStrings descendant. The same 
procedure as for any other component with an Items:TStrings property...

We could add a virtual InitLists method to the base class, that creates 
and assigns an object to FAccess (and FPageList). But the same could be 
done in every constructor, with immediate AVs when a descendant 
constructor fails to initialize these vital members.

DoDi