New TCastleTransformDesign component (like prefab for TCastleTransform), example advanced_editor showing advanced usage of designs and custom componentsPosted on December 20, 2020 by michalis New component TCastleTransformDesign allows to reference a xxx.castle-transform file inside a parent design. This way you can define a composition of TCastleTransform (including TCastleScene) inside an xxx.castle-transform file, and reuse it multiple times. It is similar to the existing TCastleDesign for user interface. New example examples/advanced_editor shows: Instantiating multiple times UI design with TSerializedComponent, TCastleDesign Instantiating multiple times transform design with TSerializedComponent, TCastleTransformDesign Registering custom components (project-specific) to be available in editor Finally, an important bug with using custom components in the editor on Unix was fixed. Share this:FacebookTwitterLinkedInRedditEmail
Right now if custom component somehow link back to units that make use of CastleWindow, then the compiler will complain about CastleWindow unit not found when try to rebuild the editor. Is there a proper way to avoid it without having to rely on ifdefs?
Right now if custom component somehow link back to units that make use of CastleWindow, then the compiler will complain about CastleWindow unit not found when try to rebuild the editor. Is there a proper way to avoid it without having to rely on ifdefs? Not really, I’m afraid (at least, not in a clean way). In order to work within the editor, the component must work with TCastleControlBase (LCL way to put CGE on Lazarus form), as entire editor is based on LCL. And you cannot link to CastleWindow in LCL applications (the CastleWindow Application tries to talk with window manager, which is incompatible with LCL trying to do the same). You could hack tools/build-tool/data/custom_editor_template/castle_editor.lpi to add there dependency on castle_window in <RequiredPackages>. It may then work (at least it will compile)… as long as what CastleWindow in initialization will not actually conflict with LCL, for which there’s no guarantee. So to be stable, I would say you have to Avoid depending on CastleWindow. Almost everything in the engine should be possible without referencing it. If you need a particular feature let me know, maybe I can add it (e.g. to TUIContainer, that largely “abstracts” the differences between TCastleWindowBase and TCastleControlBase). Or use ifdefs, as you mention.