[Lazarus] TTabControl reverted to it's old implementation

Martin lazarus at mfriebe.de
Wed Jul 27 12:22:01 CEST 2011


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







More information about the Lazarus mailing list