Community
Participate
Working Groups
Build Identifier: 20100617-1415 With GMF 2.2, I have copy/paste and DnD working from a container to another. With GMF 2.3, the DnD doesn't work. I can make it working by overriding the new generated method XXXGroupCanonicalEditPolicy.refreshSemantic calling the super method. But now the copy/paste doesn't work. There is nothing in the log. I don't understand very well what does this part of code and why the method has been added. With GMF restructuration, I can't find history of it to see the comment of the commit. I opened a thread in the forum: http://www.eclipse.org/forums/index.php?t=msg&goto=540007&#msg_540007 It happens on an highly customized editor so, for now, I can't extract an easy reproducible case. I suspect that it can cause other troubles. Any help to explain why the XXXGroupCanonicalEditPolicy.refreshSemantic has been added can be a good starting point to extract a reproducible case. Reproducible: Always
Created attachment 173208 [details] patch It seems that add a call to super at the end of the method do the trick. I don't know exactly why.
The Xpand template file flagged in your patch is actually in the GMF Tooling. The history of this file is here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmp/org.eclipse.gmf.tooling/plugins/org.eclipse.gmf.codegen/templates/diagram/editpolicies/ChildContainerCanonicalEditPolicy.xpt?root=Modeling_Project It would seem that this is a new template in GMF 2.3.0, not sure what GMF 2.2.0 had.
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
I have the same problem on not customized editor (forum thread: http://www.eclipse.org/forums/index.php?t=msg&th=174461&start=0&S=8aaafecd03ef5ca9bf02a82bf2ca3e6d). Adding super.refreshSemantic() at the end of *CompartmentCanonicalEditPolicy.refreshSemantic() solves the problem but probably isn't perfect. The funny thing is that duplication occurs then DnD from A to B and from B to A, but adding super.refreshSemantic() to only A's or B's compartment is enough to fix.
I can also confirm I've got this bug. GMF 2.3, the diagram mapping is recursive and diagram is clean generated (not customised). After I drag an element from canvas to a compartment and drop it, a diplicate ghost view is created. If then I drag the original back the ghost disappears, though if ghost is dragged, another ghost is created with first one remaining in compartment. The issue as far as I can tell is only between different container types. If an element is dragged from one container to another of same type, the behaviour is correct. Adding a super.refreshSemantic() also solved the problem. Besides, this must be added to all containers' canonical policies, as if added to only one, the ghosts appear in others. Also, if an element comes from canvas (not modified) to say container X (with this mod) and back to canvas it doesn't create a ghost, as if it keeps a history of its original creation location, as opposed to element originally from X. Another bug's behaviour is with cut & paste. If element is cut and pasted (even within the same container), instead of expected element a strange Generic Element is created with view overlaid by (x) sign. When this is saved the underlying domain element is gone. Adding call to super does not help.
Since GMF 3.0 org.eclipse.gmf.tooling.runtime.edit.policies.reparent.CreationEditPolicyWithCustomReparent which is attached to all suitable containers is expected to solve this problem.
