[Designtime editor (RE: [lazarus] Question about component structure)]

[Michal Bukovjan]

Pascal Dutilleul <pduti at yahoo.com> wrote:
> --- "Baeseman, Cliff" <Cliff.Baeseman at Greenheck.com> wrote:
> > Well I need to draw up what we need here but this is
> > the way it needs to go.
> > 
> > 
> > 1. I have to implement the anchors concept in the
> > controls that are supposed
> > to have them.
> 
> I don't think you should implement this 'into' the component.  It is
> the editor that should handle and draw those anchors.  Otherwhise a
> component could mess -up the editor. (by a custom-component that
> overwrites some anchor-handling functionality for instance)
> And what about non-visual components ?
> 
I believe in Delphi this behavior is driven via ControlStyle. There is some
design-time support in TComponent as concerns the behavior of the editor,
however, the anchors are drawn be the editor, it seems.

But I think Cliff refers to Anchors property introduced to TControl in Delphi
4, which is (at last) something that was long missing.

But there could certainly be a better solution, which is used for instance in
GTK and I suggest we incorporate that. Using Anchors as in D4, you can only
tell which borders should be resized, exactly as their parent resized, so you
have a set of [akLeft, akRight, akTop, akBottom].

If we incorporated the GTK concept, than there is 4 float numbers representing
the ratio by which the controls should resize in respective directions. 0
means no resizing (= ak* missing from the set), 1 means 100% resize (= ak*
included in the Anchors set). You can supply an arbitrary number between 0 and
1, so you can, for example, have the control resize by 50% of parent's resize
(in respective direction). This is much more flexible than Delphi solution.
And we could use integers 0-100 instead, because integer math is faster.

Also, I heard that the most flexible solution is implemented in Java Beans, so
if anyone knows about that solution, please shed a light on this.

> > 
> > 2. I have to implement the align property in
> > controls that are supposed to
> > have them.

We could kick away the Align property altogether, perhaps leaving this
property write-only to preserve Delphi compatibility, and moving its purpose
(quick alignment of a oontrol) to editor. Just an idea.

> > 
> > 3. Only certain types of controls, containers are
> > allowed to contain
> > widgets. This means that I will have to implement
> > some type of logic to
> > determine when and to what controls to  apply the
> > fixed widget.
> > 
> 
> I don't know the component hierarchy, but aren't all containers derived
> from the same base class.  Maybe you could check then the type of the
> component like 'if component is TBaseContainer then ' (I hope the 'is'
> is implemented in FPC)
No, thay aren't. Basically, every TControl descendant can be a parent. The
problem is, whether it knows how to draw its children, therefore, this is
signaled in ControlStyle.

> 
> > 5. a control without a anchor set or an align set
> > should not fire a resize
> > event or have one fired for it. For instance a
> > button does not have a
> > published resize event. It does in the existing
> > implementation but it should
> > not for delphi compatibility reasons.
> 
> What about TPanel ?  It has an published onResize, and it has anchors.
> 
Since you can resize every control by hand, every control should have the
OnResize event. Even in TButton, there may scenarios where you need OnResize
event. I remember being quite irritated when I had to embed a control to
TPanel just because that control had no OnResize event.

Michal Bukovjan


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.