Description Michael Golubev 2008-01-24 09:46:44 EST

The steps to reproduce this bug are described in the bug #213683. 
Also we can fix the 213683 by generating the patched code for reorderChild() into all of the subclasses, it seems to be simpler to fix it in the base AbstractBorderedShapeEditPart class. 
Below is the copy of my comment (https://bugs.eclipse.org/bugs/show_bug.cgi?id=213683#c2) from #213683

The issue is that class AbstractBorderedShapeEditPart overrides the method
setLayoutConstraintFor(EditPart child, IFigure childFigure, Object constraint)
but does not override the method reorderChild(EditPart child, int index) (that
is originally defined in the AbstractGraphicalEditPart).

As a result, the reordering process while trying to preserve constraint for
editpart that is being reordered, acquires the wrong constraint from "main"
content pane (line 773 of AbstractGraphicalEditPart) and sets it to "bordered"
content pane (line 776 that in turn calls the line 67 of
AbstractBorderedShapeEditPart), effectively removing the BorderLocator. 

As a simple workaround, you may add the following method into all of the edit
part classes that extends AbstractBorderedShapeEditPart (in the original
example, into the CallOperationActionXEditPart)

        protected void reorderChild(EditPart child, int index) {
                // Save the constraint of the child so that it does not
                // get lost during the remove and re-add.
                IFigure childFigure = ((GraphicalEditPart) child).getFigure();
                LayoutManager layout =
getContentPaneFor((IGraphicalEditPart)child).getLayoutManager(); //the only
change is here! getContentPaneFor() is used instead of getContentPane()
                Object constraint = null;
                if (layout != null)
                        constraint = layout.getConstraint(childFigure);

                super.reorderChild(child, index);
                setLayoutConstraint(child, childFigure, constraint);
        }