[lazarus] RFC for control structure

[Marc Weustink]

At 17:42 14-08-99 +0200, you wrote:
>I am currently working a bit on TListBox and would like top discuss, and
>if noone is against, to implement the following :
>
>1. Make a subtle change in TControl hierarchy.
>
>I thought about making a TBorderControl, which would implement border
>around a control, i.e. implement the property BorderStyle. In Delphi,
>each control that has / needs borderstyle implements it itself,
>basically the same way. It is because it is given as a parameter in
>CreateParams, and not every control supports border around. In GTK,
>however, if I want to make a border, I have to wrap the control into
>GtkFrame.

Thats a GTK problem. 

>So what I want is instead of TControl -> TWinControl -> TCustomListBox,
>which implements the border, make it somewhat more reusable, i.e.
>TControl -> TWinControl -> TBorderControl -> TListBox and just any other
>control which needs that (TListView, TTreeView, TCustomEdit, etc.)

Dont know, I like the idea of a UI independent lcl

>2. Standardize Component property
>
>Make the fComponent a regular property instead just an exposed pointer.

Thats something what I had in mind when I was writing about parents and
owners. This way you can create windows on demand.

>With regards to this, I suggest we introduce another pointer, say
>InternalComponent. This is why.
>In GTK, a lot of behaviour is accomplished through embedding components
>into another. For instance to create a listbox which is bordered and
>scrollable, I have to create GtkFrame (border), GtkScrolledWindow
>(enables scrolling its children, the listbox) and eventually GtkList.
>To reach the GtkList then, I have to cycle through the children of the
>GtkFrame, and then children of GtkScrolledWindow, which is slow. So I
>would welcome a pointer to the GtkList in question, say
>InternalComponent property. The Component property would still point to
>the top-level wrapper (GtkFrame), because some messages need this
>(resizing, etc.)

I don't think this is a way to go. In this way you add GTK specific code to
components. Couldn't you use the  fComponent pointer as a pointer to a
internal record in the interface to store all the info you need. Now the
lcl keeps independent of what grapic/user interface you use.

Marc