Description egl 2006-09-04 06:42:36 EDT

The Logic Editor example can be made to demonstrate this bug using the following steps:

1. Start with an empty diagram.
2. Drag a Flow Container from the palette to the Outline.
3. Drag an XOR Gate into the Flow Container.
4. Drag an And Gate to the Outline.
5. The Outline should now look like this:
    +--Flow Container
    |    +--XOR Gate
    +--And Gate
6. Drag the Flow Container onto its own child, the XOR Gate.  Note that the drag feedback does not indicate any inhibition of the operation.
7. The Outline now looks like this:
    +--And Gate
    +--Flow Container
         +--XOR Gate

The Reparenting (Orphan+Add combo) operation got turned into a Move!  This happens because:
1. TreeViewerTransferDropListener overrides getExclusionSet() to list all currently selected EditParts and transitively all their children too.
2. This causes AbstractTransferDropTargetListener.calculateTargetEditPart() to arrive at the toplevel LogicDiagram's LogicContainerTreeEditPart as the target editpart.
3. Which is the same as the source model object's (the Flow Container's) edit part's parent, so TreeViewerTransferDropListener.isMove() says it's a Move.
4. TreeViewerTransferDropListener.getCommand() accordingly returns such a move command.  Since the target element was not found in the children's list, the move's index is -1, so the move puts the source at the end.

Various remedies are possible, including:
1. Make the drop target feedback indicate the actual result of the move.
OR
2. Get rid of the exclusion stuff, just check for parent-children relationships, like the isAncestor() call in LogicTreeContainerEditPolicy.getAddCommand(), and disallow reparenting into child subtree.