[Lazarus] TTabControl reverted to it's old implementation

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:
> On 07/27/2011 09:03 AM, Felipe Monteiro de Carvalho wrote:
>> That's what I though initially, but it is wrong. In Delphi this
>> control allows other controls to be placed on it, so it effectively
>> has 1 sheet.
> 
> And I believe that to be a bug in Delphi. See attachment: tabcontrol.png
> 
> Dropping a Memo onto TTabControl is indeed possible, but look at the
> outcome! Components can be moved _over_ the tabs.

Isn't this *exactly* what you *can* do with a real-life notebook?

> Such behaviour should not be allowed.

Overlapping components can occur everywhere, and may have their place in 
some (CAD...) applications. I see no need to restrict an GUI designer in 
any way, but of course there should exist means to prevent unwanted 
overlapping, when components are resized at runtime (tabs added, labels 
enlarged for a translated heading...). All that is not restricted to 
tabbed controls.

> Yet when you set the Memo1.Align := alClient, then in
> maximizes the memo to fit underneath the tabs. This is very conflicting
> behaviour -

IMO this is just one solution for above problems, where do you see any 
conflict?

If you are not happy with this solution, then separate the tabs from the 
"body", and put all related components into an dedicated (notebook) 
container, and make sure that it never will overlap the tabs. But what 
when a multi-line tabctrl will expand itself when tabs are added? Then 
*you* (designer) are responsible again for handling overlaps.


> Use a tool like MWSnap 3's "window information" feature. This allows you
> to move the mouse over applications (even better if they are Delphi
> apps) and it tells you the components used, and outlines the component
> bounds.

This is what the Delphi Winspector already did years ago [dunno remember 
the exact name of that tool]. Such tools rely on all controls being 
handled by a known widgetset, what is not true for e.g. Java (or newer 
Qt?) applications, with their own component management. The same on 
non-Windows platforms, where only windows are managed by a known window 
manager, while all controls are implemented by some widgetset (qt, 
gtk...), which is not known to the outer world.


>> I also use it in apps where you click on a button and then part of the
>> view changes to reflect which tool is selected.
> 
> I simplified this whole tab/notebook mess in fpGUI. I have one
> PageControl component.

This is what we have in Lazarus, too. What's so bad with having *more* 
components - except that somebody has to supply and support every component?


> You really don't need
> 5 components as is done in Delphi. Even Borland noticed that, because
> Delphi 7 CLX or Kylix has limited it to two components only.

You obviously missed the compatibility issue :-(

Delphi 1 has implemented treeviews, tabs and notebooks, which have not 
been available on the Win3.x platform. When Microsoft later implemented 
a tabbed control, they didn't follow the Delphi model, so that now 
Delphi offers new Win32 (COM) compatible components, as well as legacy 
(Win3.1) components.

These different models obviously also confused the Lazarus developers, 
leading to inconsistent or incompatible implementations of all these 
components. Nowadays we may agree to drop support for the Delphi 1 
components from the LCL, but we could as well retain the legacy 
components in their own (Win3.1) package, possibly with limited support 
on newer widgetsets.

But while the developer of an widgetset is free in the choice and 
implementation of its own (fpGui...) components, the LCL should support 
the native widgets, provided by a platform or widgetset. This is where 
problems with the different widget models arise, when e.g. gtk2 provides 
a tabbed control that is quite different from its Win32 counterpart. And 
it doesn't help to point out how something *should* be implemented, when 
an existing widgetset implements a different model for a complex control.

DoDi