Mattias Gärtner schrieb:
The description of BorderSpacing is not very clear, can you improve it?
I tried. See here:
http://wiki.lazarus.freepascal.org/Autosize_/_Layout#BorderSpacing
Much better now :-)
In a generalized layout management every control could be adjustable
inside the cell,
Zitat von Hans-Peter Diettrich :
Mattias Gaertner schrieb:
BorderSpacing and ChildSizing IMO are specific to an layout
manager, meaningless to other layout managers. BorderSpacing IMO
is equivalent to the Delphi anchors.
They are not equivalent. Delphi Anchors are only the space to the
pa
Mattias Gaertner schrieb:
BorderSpacing and ChildSizing IMO are specific to an layout manager,
meaningless to other layout managers. BorderSpacing IMO is equivalent to
the Delphi anchors.
They are not equivalent. Delphi Anchors are only the space to the
parent. BorderSpacing allows to define
On Thu, 08 Apr 2010 00:20:32 +0200
Hans-Peter Diettrich wrote:
> Michael Van Canneyt schrieb:
>[...]
> BorderSpacing and ChildSizing IMO are specific to an layout manager,
> meaningless to other layout managers. BorderSpacing IMO is equivalent to
> the Delphi anchors.
They are not equivalent.
Mattias Gärtner schrieb:
Borderspacing properties could be used too in all layouts (I can
imagine) and for consistency I recommend that they are used - at least -
in a similar way. This is more a design guide line.
IMO BorderSpacing should be implemented using the Delphi anchors.
Clearing pr
Michael Van Canneyt schrieb:
"The space of BorderSpacing and of the parent's ChildSizing is applied to
aligned controls. The memo below has Align=alClient"
BorderSpacing has nothing to do with border style or bevels. It is an EXTRA
margin. Border style and bevels determine the ClientRect of a c
Zitat von Michael Van Canneyt :
On Wed, 7 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
IMO it's quite simple. A layout affects the position of child
controls inside a container control, nothing else. Borders,
Constraints and Autosize are general properties of all c
Zitat von Alexander Klenin :
On Wed, Apr 7, 2010 at 22:47, Michael Van Canneyt
wrote:
I agree for Constraints, but not the other two.
Funny, I just argued exactly the other way around ;-)
Some properties must be handled by all Layouters. For example the
interface constraints (you can not
On Wed, 7 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
IMO it's quite simple. A layout affects the position of child controls
inside a container control, nothing else. Borders, Constraints and
Autosize are general properties of all controls, which must be handled
in/b
Michael Van Canneyt schrieb:
IMO it's quite simple. A layout affects the position of child controls
inside a container control, nothing else. Borders, Constraints and
Autosize are general properties of all controls, which must be handled
in/by the control itself.
I agree for Constraints, but
On Wed, Apr 7, 2010 at 22:47, Michael Van Canneyt
wrote:
> I agree for Constraints, but not the other two.
Funny, I just argued exactly the other way around ;-)
--
Alexander S. Klenin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
h
On Wed, Apr 7, 2010 at 21:24, Hans-Peter Diettrich wrote:
>>> Only Align, Anchors and ChildSizing.Layout are layouts. The rest are
>>> details that apply to all layouts. See the layouters of gtk.
>>
>> In my view, this is not correct. Borderspacing, Constraints and AutoSize
>> are also properties
On Wed, 7 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Now the TControl/TWinControl classes have a set of properties that is the
union of all properties of a large set of layouters (because it must
mimic
the behaviour of all these layouters put together):
* AutoS
Michael Van Canneyt schrieb:
Now the TControl/TWinControl classes have a set of properties that is
the
union of all properties of a large set of layouters (because it must
mimic
the behaviour of all these layouters put together):
* AutoSize
* Anchors
* Align
* Constraints
On Wed, 7 Apr 2010, Mattias Gaertner wrote:
On Tue, 6 Apr 2010 15:33:54 +0200 (CEST)
Michael Van Canneyt wrote:
[...]
How can a designer tool find out what layout a control uses?
Why does it need to know ?
If it needs to know what layout a control uses, the designer is flawed by
design:
On Tue, 6 Apr 2010 15:33:54 +0200 (CEST)
Michael Van Canneyt wrote:
> [...]
> > How can a designer tool find out what layout a control uses?
>
> Why does it need to know ?
>
> If it needs to know what layout a control uses, the designer is flawed by
> design:
>
> There may be layouters that th
On Tue, Apr 6, 2010 at 1:09 PM, Hans-Peter Diettrich
wrote:
> Many widgetsets support controls for specific layouts. Shouldn't Lazarus try
> to use just these controls?
No, that would a horrible mess and terrible to maintain.
At least for controls there are good reasons to use native controls
an
Michael Van Canneyt schrieb:
I would be very surprised to see more than 4 layouters on a form.
Most forms will have a single TTableLayout or TBorderLayout
component, and that's it.
How do you know?
Simple experience.
AFAIR the IDE is a counter example.
Most controls will not have a need
On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
There is much stuff that doesn't make sense for all controls.
That should be a good reason for not adding more stuff.
... and to remove existing specific layout stuff.
What should be complicated, when the Delp
Michael Van Canneyt schrieb:
There is much stuff that doesn't make sense for all controls.
That should be a good reason for not adding more stuff.
... and to remove existing specific layout stuff.
What should be complicated, when the Delphi layout manager is one of
multiple available mana
On 06/04/2010 15:41, Alexander Klenin wrote:
1. Only TControls can be put into TWinControl and a layouter is not a visual
thing itself.
2. a layouter can be used by several controls.
Ok, I agree with Michael and Mattias that a separate layout component
and a TWinControl.Layout property is
>1. Only TControls can be put into TWinControl and a layouter is not a visual
>thing itself.
>2. a layouter can be used by several controls.
Ok, I agree with Michael and Mattias that a separate layout component
and a TWinControl.Layout property is the only way that satisfies all
the requirements.
On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I wonder how you want LCL code to use a dropped layout component. When no
predefined property exists, every TWinControl had to be searched for an
according component, whenever a layout method or property shall be
Martin schrieb:
Either you need a special property editor, which opens for the Layouter,
and allows you to add/remove controls. Or you have a Layouter property.
IMHO the property would be fine in this case.
ACK. Like the Font property, the properties of the selected layouter can
be edited in
Alexander Klenin schrieb:
How about Layouter grabbing control of its Parent?
So you can put it on the panel, and it will guide the layout of all
child controls of that panel --
seems logical to me.
This method could work, of course.
But the component will consume space in the control at desig
Michael Van Canneyt schrieb:
I wonder how you want LCL code to use a dropped layout component. When
no predefined property exists, every TWinControl had to be searched
for an according component, whenever a layout method or property shall
be accessed.
I would use a mechanism similar to the d
On Tue, 6 Apr 2010, Mattias Gärtner wrote:
Zitat von Michael Van Canneyt :
On Tue, 6 Apr 2010, Mattias Gärtner wrote:
Zitat von Michael Van Canneyt :
[...]
I would use a mechanism similar to the datalink. As soon as you tell
the
layout manager to manage a certain control, a hook is
Zitat von Michael Van Canneyt :
On Tue, 6 Apr 2010, Mattias Gärtner wrote:
Zitat von Michael Van Canneyt :
[...]
I would use a mechanism similar to the datalink. As soon as you tell the
layout manager to manage a certain control, a hook is installed in the
control.
And where is the hook
Zitat von Alexander Klenin :
On Tue, Apr 6, 2010 at 22:52, Martin wrote:
I can see that work, if a Layouter was always global => drop it on a Form,
and the Layouter will grab control of all controls on the Form.
But if you want selective Autosizing (eg, just PanelX should use the
Layouter, th
On Tue, 6 Apr 2010, Mattias Gärtner wrote:
Zitat von Michael Van Canneyt :
[...]
I would use a mechanism similar to the datalink. As soon as you tell the
layout manager to manage a certain control, a hook is installed in the
control.
And where is the hook stored?
In TWinControl, protect
On Tue, Apr 6, 2010 at 22:52, Martin wrote:
> I can see that work, if a Layouter was always global => drop it on a Form,
> and the Layouter will grab control of all controls on the Form.
>
> But if you want selective Autosizing (eg, just PanelX should use the
> Layouter, the rest uses the default,
On 06/04/2010 10:33, Michael Van Canneyt wrote:
With a dedicated LayoutManager property, all anchor-docking related
stuff
could be moved from TWinControl into the AnchoredLayoutManager, and
DockManager could be replaced (or merged with) the LayoutManager.
In further
steps the DockClient list co
Zitat von Michael Van Canneyt :
[...]
I would use a mechanism similar to the datalink. As soon as you tell the
layout manager to manage a certain control, a hook is installed in the
control.
And where is the hook stored?
In TWinControl, protected or even private.
And how to find out which
On Tue, 6 Apr 2010, Mattias Gaertner wrote:
On Tue, 6 Apr 2010 10:48:58 +0200 (CEST)
Michael Van Canneyt wrote:
On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I have been thinking about layout managers. I think that this should be
an add-on
to the current
On Tue, 6 Apr 2010 10:48:58 +0200 (CEST)
Michael Van Canneyt wrote:
>
>
> On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:
>
> > Michael Van Canneyt schrieb:
> >
> I have been thinking about layout managers. I think that this should be
> an add-on
> to the currently existing lay
On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I have been thinking about layout managers. I think that this should be
an add-on
to the currently existing layouting (to preserve delphi compatibility): I
imagine a component that one drops on a form. One sets the
Michael Van Canneyt schrieb:
I have been thinking about layout managers. I think that this should
be an add-on
to the currently existing layouting (to preserve delphi
compatibility): I imagine a component that one drops on a form. One
sets the 'target' control (control whose children should be
Michael Van Canneyt schrieb:
A small follow-up on this:
1. What code is needed or can be used in Lazarus ?
In the OnDockDrop event, The width/height of the control which will
be docked
are no longer available. (they are 0, with the latest lazarus, no
-dOldAutoSize,
and the panel to
On Mon, 05 Apr 2010 22:25:06 +0200
Birger Jansen wrote:
> Sorry for dropping into the discussion...
>
> There is a very good LAyoutControl in the DevExpress suite (Delphi
> controls). We use it for a lot of projects. I think it is an excellent
> example of how a layout manager could work in th
Sorry for dropping into the discussion...
There is a very good LAyoutControl in the DevExpress suite (Delphi
controls). We use it for a lot of projects. I think it is an excellent
example of how a layout manager could work in the ideal world:
http://www.devexpress.com/Products/VCL/ExLayoutCon
On Mon, 5 Apr 2010, Martin wrote:
On 05/04/2010 20:26, Michael Van Canneyt wrote:
I tried to test, but rev. 2 of the IDe does not compile;
SourceEditor.pp does not compile.
My fault, Fixed in 24445
Thanks :)
Michael.
--
___
Lazarus maili
On 05/04/2010 20:26, Michael Van Canneyt wrote:
I tried to test, but rev. 2 of the IDe does not compile;
SourceEditor.pp does not compile.
My fault, Fixed in 24445
Martin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://
On Mon, 5 Apr 2010 18:26:36 +0200 (CEST)
Michael Van Canneyt wrote:
>[...]
> I have been thinking about layout managers. I think that this should be an
> add-on to the currently existing layouting (to preserve delphi
> compatibility):
> I imagine a component that one drops on a form.
> One se
On Mon, 5 Apr 2010, Mattias Gaertner wrote:
On Mon, 5 Apr 2010 10:48:00 +0200 (CEST)
Michael Van Canneyt wrote:
On Mon, 5 Apr 2010, Mattias Gaertner wrote:
On Sun, 4 Apr 2010 19:21:00 +0200 (CEST)
Michael Van Canneyt wrote:
Hi,
In delphi, setting a panel's AutoSize property to 'true
On Mon, 5 Apr 2010 10:48:00 +0200 (CEST)
Michael Van Canneyt wrote:
>
>
> On Mon, 5 Apr 2010, Mattias Gaertner wrote:
>
> > On Sun, 4 Apr 2010 19:21:00 +0200 (CEST)
> > Michael Van Canneyt wrote:
> >
> >> Hi,
> >>
> >> In delphi, setting a panel's AutoSize property to 'true' and aligning it
On Mon, 5 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I have been thinking about layout managers. I think that this should be an
add-on
to the currently existing layouting (to preserve delphi compatibility): I
imagine a component that one drops on a form. One sets the
Michael Van Canneyt schrieb:
I have been thinking about layout managers. I think that this should be
an add-on
to the currently existing layouting (to preserve delphi compatibility):
I imagine a component that one drops on a form. One sets the 'target'
control (control whose children should be
by 10 pixels in every direction. It it used only in the determination of
the target site, not in the layout.
I know. That is why setting
No code is needed, and you can then dock toolbars etc. along the edges of
the form.
Code is needed to extend and shrink the sites - also in Delphi.
On 05/04/2010 17:26, Michael Van Canneyt wrote:
I already asked for an (user selectable) layout manager some time
ago. Such a manager would replace or include docking managers, that
essentially control the *layout* of a docksite, while docking itself
is only a minor addition. Then AutoSize sh
On Mon, 5 Apr 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
In Delphi, you can make dock zones along the edges of your
form by dropping 4 panels and aligning them along the edges of the form. If
autosize=true, then they have size 0 when the app is run (not when
designed),
Michael Van Canneyt schrieb:
In Delphi, you can make dock zones along the edges of your
form by dropping 4 panels and aligning them along the edges of the form.
If autosize=true, then they have size 0 when the app is run (not when
designed), but you can dock controls on them, since there is a
Mattias Gaertner schrieb:
In delphi, setting a panel's AutoSize property to 'true' and aligning it to a
form edge, makes the panel disappear when the project is run.
This is logical, because, if there are no controls on the panel,
the needed size is zero.
Yes, and this is the problem. A visib
On Mon, 5 Apr 2010, Mattias Gaertner wrote:
On Sun, 4 Apr 2010 19:21:00 +0200 (CEST)
Michael Van Canneyt wrote:
Hi,
In delphi, setting a panel's AutoSize property to 'true' and aligning it to a
form edge, makes the panel disappear when the project is run.
This is logical, because, if there
On Sun, 4 Apr 2010 19:21:00 +0200 (CEST)
Michael Van Canneyt wrote:
> Hi,
>
> In delphi, setting a panel's AutoSize property to 'true' and aligning it to a
> form edge, makes the panel disappear when the project is run.
> This is logical, because, if there are no controls on the panel,
> the n
On Sun, 4 Apr 2010, Michael Van Canneyt wrote:
Hi,
In delphi, setting a panel's AutoSize property to 'true' and aligning it to a
form edge, makes the panel disappear when the project is run.
This is logical, because, if there are no controls on the panel, the needed
size is zero.
In Lazar
Hi,
In delphi, setting a panel's AutoSize property to 'true' and aligning it to a
form edge, makes the panel disappear when the project is run.
This is logical, because, if there are no controls on the panel,
the needed size is zero.
In Lazarus, the panel is still shown.
Is this a known bug
56 matches
Mail list logo
