Sign in Join

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

Mailing lists / lazarus / 1999-08

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

1 message · 1 person ·

Reply by email Subscribe to this list Your subscription

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

Michal Bukovjan
Pascal Dutilleul wrote 15 lines
--- "Baeseman, Cliff" 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.

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

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

Reply by email