On 27/07/2011 08:58, Graeme Geldenhuys wrote:
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.
If I had to guess, I would say that Delphi has the client-area (never
mind the overlap), because Delphi does not have the same anchors as
Lazarus. So it is more often required to nest components, to archive a
layout. Just a guess...
Anyway, as for an implementation in Lazarus, I would think it would be
good to replicate. even if only for compatibility, so people can convert
there Delphi projects.
Lazarus can add the autosize, which would make it a tab only control,
and the client area could be left empty.It would be the developers choice.
As for the overlap, and the Child.Top = 0 location.
In Delphi Child.Top = zero means overlap the tabs (as does it for
TGroupBox).
IMHO I see no unsolvable issue, if that was different in Lazarus. The
Delphi-Convertor could probably adjust the Top coordinates of a
TTabControl's direct children.
NoteBook - I have no idea what is the difference between this and
the PageControl. They seem the same to me. The only
difference I could see is how you add more tabs. One use
a string list property the other is a collection of
page objects (I think).
That's how it was implemented before I fixed it. The correct TNotebook
has no tabs, only sheets without any border.
You are correct about TNotebook, but I was thinking of the
TTabbedNotebook as can bee seen in Delphi 7. Then again, having a
Notebook, TabbedNotebook, PageControl, TabControl etc. is just damn
confusing to developers.
Notebooks are CustomControls (haven't checked TTabedNotebook...)
Tab/PageControl are Wincontrol
There are other occasions of very similar components, that mainly differ
in this inheritance point 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.
Do you have a difference between WinControls and none WinControls? Or
actually do you have a need for it?
probably not... Though I don't know how InvalidateRect is implement for
fpGui? You must have some interaction with the OS/Widgetset there, as
invalidation can happen from outside the app
Anyway, in W32 (and probably others too) If I invalidate multiply rects
of the same WinControl (a wincontrol has a handle in the OS) then the
minimum bounding rect is invalidated => so I may end up painting more
than actually required.
If I have separate WinControls, then each of them has it's invalidated
rect (and each will get a callback invoking it's Paint.
So it's a question if you have a very time-expensive paint handler, you
may want to have more handles, and paint less
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
