|
|
|
|
|
Re: dangling steoretypes after deleted stereotyped elements [message #1831136 is a reply to message #1831083] |
Wed, 12 August 2020 05:31   |
Eclipse User |
|
|
|
Thanks to both of you!
I tried to add the eBasicSetContainer, it did not solve the problem, but maybe I did it wrong, I will try it again later.
In debugging from didRemove(...) I found the following:
First, I realized that I get dangling stereotypes not only for stereotyped elements from my Static Profile and Context, but also when I create an element with a stereotype from a dynamic profile. (I hope I'm using all the terms correctly)
When I have the plug-ins with my architecture context & profile in my workspace, didRemove(...) is not called when I delete an element, and resource is never not null in remove(EObject eObject) in org.eclipse.emf.ecore.util.EcoreUtil
I compared with a workspace WITHOUT these plugins. There, deleting works correctly without the dangling problem. When a stereotyped element is deleted, resource != null for a DynamicEObjectImpl in remove(EObject eObject) in org.eclipse.emf.ecore.util.EcoreUtil
With my plug-ins, doExecuteWithResult(...) in DestroyElementCommand.class is not called at all for a DynamicEObjectImpl when I delete an element from a diagram. doExecuteWithResult(...) is still called for
an OpaqueActionImpl, CSSDecorationNodeImpl, LocationImpl, CSSDecorationNodeImpl,...
I guess this means the DynamicEObject is not deleted? How can I continue with this information?
[Updated on: Wed, 12 August 2020 05:32] by Moderator
|
|
|
|
Re: dangling steoretypes after deleted stereotyped elements [message #1831147 is a reply to message #1831136] |
Wed, 12 August 2020 07:48   |
Eclipse User |
|
|
|
Susanne Fuchs wrote on Wed, 12 August 2020 05:31With my plug-ins, doExecuteWithResult(...) in DestroyElementCommand.class is not called at all for a DynamicEObjectImpl when I delete an element from a diagram. doExecuteWithResult(...) is still called for
an OpaqueActionImpl, CSSDecorationNodeImpl, LocationImpl, CSSDecorationNodeImpl,...
I guess this means the DynamicEObject is not deleted? How can I continue with this information?
This is an interesting finding. The StereotypeApplicationAdvice ought to be delegating (indirectly) to the DestroyElementCommand (or some subclass, I suppose) to effect deletion of the applied stereotypes.
Can you debug this advice to see whether it finds stereotype applications to delete and, if not, why not? And if this advice isn't involved in your scenario, then it would be necessary to put a breakpoint in the ElementImpl::eBasicSetContainer method to see what kind of command is actually deleting the element that is leaving the dangling stereotypes behind and trace where that command is coming from, to see why the usual edit-helper advice flow is not happening.
Christian
|
|
|
|
Powered by
FUDForum. Page generated in 0.10847 seconds