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