Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-08

RFC for control structure

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Samuel Liddicott
to Marc Weustink: Thats a GTK problem. Dont know, I like the idea of a UI independent lcl Thats something…
Show quoted text 11 lines
-----Original Message----- From: Marc Weustink Sent: 15 August 1999 11:36 PM To: Subject: Re: [lazarus] RFC for control structure >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.

I agree. Surely *some* other GTK users will want this, it should be added as a GTK feature.

Show quoted text 6 lines
>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.

What is the fcomponent for? I can't find any example of its use in the lcl.

Sam

Reply by email

Marc Weustink
to Michal Bukovjan: I am currently working a bit on TListBox and would like top discuss, and if noone is…
you wrote 12 lines
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.

Show quoted text 12 lines
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

Reply by email

Michal Bukovjan

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.

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

2. Standardize Component property

Make the fComponent a regular property instead just an exposed pointer. 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.)

Michal Bukovjan

Reply by email