Problems with anchors in a custom component

[simsee]

I'm writing a package with a component composed of three subcomponents (a treeview, a splitter and a synedit).

Everything seems to work, except for the anchors. When I set the border space of an anchor with the anchor editor, this is effective in the form editor, but not at run time. Furthermore, if I close the project, when I reopen it the border space previously set, is zeroed.

This is the code of the component.

Code: Pascal  [Select][+][-]

1. unit UExplorer;
2. {$mode ObjFPC}{$H+}
3.  
4. interface
5.  
6. uses
7.   Classes, SysUtils, StrUtils, Forms, Controls, Graphics, Dialogs, ComCtrls, ExtCtrls,
8.   SynEdit, Contnrs;
9.  
10. type
11.  
12.   { TExplorer }
13.  
14.   TExplorer = class(TCustomControl)
15.   private
16.     fTreeView : TTreeView;
17.     fSplitter : TSplitter;
18.     fSynEdit : TSynEdit;
19.  
20.   protected
21.  
22.   public
23.     constructor Create(AOwner: TComponent); override;
24.  
25.   published
26.     property Align;
27.     property Anchors;
28.     property TreeView : TTreeView read fTreeView;
29.     property Splitter : TSplitter read fSplitter;
30.     property SynEdit : TSynEdit read fSynEdit;
31.   end;
32.  
33. procedure Register;
34.  
35. implementation
36.  
37. procedure Register;
38. begin
39.   RegisterComponents('Additional',[TExplorer]);
40. end;
41.  
42. { TExplorer }
43.  
44. constructor TExplorer.Create(AOwner: TComponent);
45. begin
46.   inherited Create(AOwner);
47.   SetInitialBounds(0,0,300,200);
48.  
49.   fSplitter:=TSplitter.Create(Self);
50.   with fSplitter do
51.     begin
52.       Name:='Splitter';
53.       Parent:=Self;
54.       Left:=1;
55.       Align:=alLeft;
56.       SetSubComponent(true);
57.     end;
58.  
59.   fTreeView:=TTreeView.Create(Self);
60.   with fTreeView do
61.     begin
62.       Name:='TreeView';
63.       Parent:=Self;
64.       Align:=alLeft;
65.       SetInitialBounds(Left,Top,50,Height);
66.       ReadOnly:=True;
67.       SetSubComponent(true);
68.     end;
69.  
70.   fSynEdit:=TSynEdit.Create(Self);
71.   with fSynEdit do
72.     begin
73.       Name:='SynEdit';
74.       Clear;
75.       Parent:=Self;
76.       Align:=alClient;
77.       SetInitialBounds(Left,Top,150,Height);
78.       SetSubComponent(true);
79.     end;
80. end;
81.  
82. end.

I attach my package and the test code to reproduce the problem.

Thanks.

[Martin_fr]

Maybe if you published BorderSpacing?

You are a custom control, a lot of properties aren't published. And apparently anchor edit bypasses this and allows to edit the non published spacing.

[simsee]

Thanks for the suggestion, that solves the problem.

I was thinking of making the BorderSpacing property published, but I didn't think it would affect the behavior of the anchor editor.

By the way, since TControl and its descendants have many published properties, what is the minimum set of indispensable properties that in a component must be published for its basic correct functioning?

[Martin_fr]

By the way, since TControl and its descendants have many published properties, what is the minimum set of indispensable properties that in a component must be published for its basic correct functioning?

Define "functioning".

(Usually) All properties work never mind if they are published. "work" means, that if you set them in code, they will behave.

For the purpose of this thread, you need published if
- you want to see the property in the object inspector (not accounting for custom prop edits (like the anchor edit))
- safe them to lfm

So, if your components needs to have a value set at design time, and needs to store it in the lfm, then for that component to function, that property must be published.

Or it must be handled by overriding the method that allows to stream extra fields.

"Usually" / "purpose of this thread":

There are other uses, such as streaming for database/orm or streaming for REST or other transfer/storage formats.
Also various other RTTI based implementations.

[simsee]

Thanks Martin for your very helpful reply.

I imagine similar considerations for event properties. In this case, I presume, I also need to override the corresponding event handler method (e.g. TControl.DblClick in the case of the OnDblClick property).

[Martin_fr]

I imagine similar considerations for event properties. In this case, I presume, I also need to override the corresponding event handler method (e.g. TControl.DblClick in the case of the OnDblClick property).

What exactly to you try to do?

I mean yes, if you wont your TExplorer  do have a double click event that you can set in the object inspector, then you need to make that even published. That would just be a line "property OnDoubleClick" in the published section (no read or write specifier).

But that seems pointless. Your TExplorer  is fully covered by the components that it includes. So where ever you click that click will go to one of the embedded components. The TExplorer  will never get a click.

So you would need (in code) to do

Code: Pascal  [Select][+][-]

1. synedit.OnDoubleClick := MyClickHandler;

and then from there trigger the double click of the TExplorer.

[simsee]

Yes, you are right. In this case, the embedded subcomponents, which are exposed in the object inspector with SetSubComponent(true), can receive and handle events, setting their properties.

I was just wondering if it would be useful for the component users to have global events available.