|Re: Intended behaviour of ItemPropertyDescriptorDecorator [message #1693486 is a reply to message #1693371]
||Fri, 24 April 2015 13:49
| Ed Merks
Registered: July 2009
On 23.04.2015 17:08, Erlend Stav wrote:
> What is the intended behaviour of the ItemPropertyDescriptorDecorator?
> From the EMF book example and other references I have seen, my
> expectation was that this class was a convenience class that by default
> forwards all the calls to the IItemPropertyDescriptor provided in the
> constructor, and that it would be useful when you just want to override
> a couple of methods from the interfaces.
No, it's generally easiest to override the implementation that's
otherwise being used. I.e., to specialize a property descriptor one
generally create a derived implementation in the item provider method
where the property descriptor is created.
> However, the implementation of almost the methods ignores the thisObject
> parameter, and instead uses the object that you set in the constructor
> when it forwards the call to the original IItemPropertyDescriptor.
> From the documentation of the class, it is not possible to see if this
> is an intended feature or whether it is a systematic bug in most of the
> The effect when using the decorator class in customisation of
> item providers (like shown in the EMF book) is that unless you change
> the default generated getPropertyDescriptors class to always generate
> new itemPropertyDescriptors, the property editor will only work
> correctly for the first object you select of the type you have decorated.
Unless you make the item providers stateful so a new one is created for
Powered by FUDForum
. Page generated in 0.02543 seconds