TTreeNodes PropertyEditor

[Sieben]

I'm currently working on a descendant of TCustomTreeView and had to find that the Items property won't show up in OI despite being published with the new component. Reason why seems to be simple: TTreeViewItemsProperty editor is registered only for TTreeView, not TCustomTreeView - soon as I derive from TTreeView the property and it's editor show up as expected. Same for TTreeViewComponentEditor btw.

Question is: are there any good reasons not to register these editors with TCustomTreeView - or TCustom* components in general - and when there are, what ist the proper way to work around this without reinventing the wheel?

[jamie]

did u republish everything ?

[Sieben]

No, and that's exactly the reason why I want to descend from TCustomTreeView...

[wp]

I'm currently working on a descendant of TCustomTreeView and had to find that the Items property won't show up in OI despite being published with the new component. Reason why seems to be simple: TTreeViewItemsProperty editor is registered only for TTreeView, not TCustomTreeView - soon as I derive from TTreeView the property and it's editor show up as expected. Same for TTreeViewComponentEditor btw.

Question is: are there any good reasons not to register these editors with TCustomTreeView - or TCustom* components in general - and when there are, what ist the proper way to work around this without reinventing the wheel?

Simply repeat the registration for your component, look at TreeViewPropEdit in components/ideintf how the treeview design editors are registered.

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

1. procedure Register;
2. begin
3.   // This is your component registration
4.   RegisterComponents('My components', [TMyTreeView]);
5.  
6.   // This is adapted from TreeViewPropEdit
7.   RegisterComponentEditor(TMyTreeView,TTreeViewComponentEditor);
8.   RegisterPropertyEditor(ClassTypeInfo(TTreeNodes), TMyTreeView, 'Items', TTreeViewItemsProperty);
9. end;

[Sieben]

Thanks, that's fairly easy. And I could have thought of that myself... For lurkers: add IDEIntf as a requirement to your package and ComponentEditors, PropEdits, TreeViewPropEdit (resp the propedit unit required for your component) to the implementation uses of your unit.

[wp]

For lurkers: add IDEIntf as a requirement to your package

Yes, thanks, I forgot to mention this. There is a disadvantage in this, however: ideintf pulls a lot of code into your exe which is not needed at runtime: all the property and component editors, as well as the component palette icons. Therefore, it is recommended to create a second package, which is marked in its properties for DesignTime Only (or RunTime and DesignTime); and in this package you should "use" ideintf and call the registration.

[Sieben]

Thanks again. And this second package should 'use' the original component package then? And should this second package manage all 'Registers' then or just the editors?

[wp]

Have a look a the datetimecontrols package which comes with the IDE (folder components/datetimectrls. You can find some other components strictly distinguishing between runtime and designtime packages on CCR (TvPlanIt, JVCLLaz, fpspreadsheet).

datetimectrls.lpk is the runtime package, it only contains the component code only, no registration, no resource file with the palette icons, no ideintf. In this particular example the package properties mark it as "Designtime and runtime" - I'd use "Runtime" or "Runtime only", though.

In subfolder "design", there is the designtime package, datetimectrlsdsgn.lpk. It "requires" the runtime package and the ideintf package. In contains the registration unit (datetimectlsreg.pas) which registers each component as well as their property/component editors. Also, the {$R <paletteicons>.res} is there. You can register different components in the same unit. Again, in this example the package is marked as "Designtime and runtime", but I'd recommend a "Designtime" instead.

Important note: either have all units in the same folder, or put runtime and designtime code into separate directories, and also make sure that the compilation destinations are different (the lpk files can be in the same folder). Otherwise you may have problems building the IDE.

When everything is set up correctly the IDE will present you only the runtime package to be used in a project.

Many simple packages still use combined runtime/designtime packages. This may be fine for simple packages with a few components only, but large combined packages will sooner or later run into trouble.

[Sieben]

Thank you very much, that's very instructive. I'm glad now I did not find the 'simple' solution by myself but had to ask this question here. So when 'distributing' components for Lazarus it would be advisable to not only give away a unit with Register procedures and leave the choice of 'packaging' to the user (like I did with Delphi years ago) but to include a package structure as well?