[Re: [lazarus] RFC for control structure]

[Michal Bukovjan]

Marc Weustink <weus at quicknet.nl> wrote:
> 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. 

That is not a problem, that's the way it was designed. And thinking about
that, it might not be a bad idea after all.

> 
> >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

It is still independent. In fact, it is usable even in Windows, I think the
border constant is the same for all controls. But then again, I may be wrong.
But through this change, the border could be reused, not jest re-programmed
for every control that need a frame around.

> 
> >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.

Yes.

> 
> >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.
> 
I thought about it some more, and the need is not that strong, after all. It
is not GTK specific, though, because other widget set (unlike Windows
controls, which are not object oriented) might need that too.

I cannot keep just a pointer to record, because that would require to rewrite
the whole gtkint/gtkobject stuff.

I found, however, that if I keep the lowermost child (the actual control in
question), I can get to its internal parent (aka frame, or srollingwindow)
relatively fast.

I will think and experiment about it some more, and wait until the
IntSendMessage stuff gets united.

Regards,

Michal Bukovjan