Am 10.11.2019 um 22:26 schrieb Sven Barth:
Hello together!
I've got a RFC for a feature that allows to extend the IDE. It's based
on something that Delphi supports as well: Selection Editors.
Unlike Component Editors these are supposed to be used to interact
with a specific selection in the designer and (in Delphi) allow the
following extensions:
- adding menu items for the context menu for the selection (like
component editors)
- add additional units when the component is dropped onto the form
(though I wonder why that isn't part of component editors)
- add or remove properties to/from the object inspector for the selection
My current RFC only implements the last one and also a bit different
than Delphi does cause they added that functionality only later (see
below).
Due to their dependencies Selection Editors live in the PropEdits unit
and like component and property editors they are registered at an
approbriate location (be it some Register function or a unit
initialization). When the object inspector requests the properties it
also checks all selection editors involved in the selection (included
the parent classes) and calls the selection editor's FilterProperties
method if GetAttributes contains seaFilterProperties (Delphi does not
provide a GetAttributes method, instead it provides FilterProperties
through an interface that needs to be implemented by a selection editor).
FilterProperties receives both the current selection of the object
inspector as well as the list of property editors. It is then free to
add or remove property editors as it sees fit.
The behavior when collecting the property editors is such that
multiple FilterProperties methods might be called on the same
selection, thus it might received an already filtered property editor
list.
I've attached a patch that implements selection editors
(selection-editors.patch) as well as an example implementation for a
component that Lazarus already supports and Delphi provides a
selection editor for: TFlowPanel (tflowpanel-seledit.patch). For that
component for each child control a virtual ControlIndex property is
exposed which allows to easily change the order of the components in
the object inspector instead of going through some collection editor.
Also the Top and Left properties are removed as they aren't useful for
such components. Delphi behaves the same here.
Another example use would be TGridPanel which we don't have yet: it
allows to implement the Row- and ColumnSpan properties on each child
control of the panel.
To work correctly I also had to adjust the object inspector a little
bit (respect-parevertable.patch), cause it is not using only the
virtual functions provided by TPropertyEditor: namely to respect the
paRevertable attribute and only initialize and use the undo values if
the property is deemed revertable. For demonstration purposes I've
disabled the paRevertable attribute for the ControlIndex property
editor, cause otherwise there'd be an exception when the object
inspector tries to read the original value. It would be better if the
object inspector would only call virtual methods of TPropertyEditor
however or ones that can be easily faked (like I did by faking a
TPropInfo entry, though that does not feel really nice either).
Suggestions and criticism are welcome though I can't tell how much
time I currently can and want to invest to improve this further. It
might also need some step-by-step improvement of the existing
TPropertyEditor interface to function smoothly.
Really? No further interest here? I don't want to put it on Mantis yet,
because I'm not yet sure whether everything is alright and Mantis is not
a discussion platform...
Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
