| EcoreUtil.replaceEObject() causes layout problem with dropped object [message #204289] |
Wed, 03 September 2008 13:44  |
Eclipse User |
|
|
|
Originally posted by: tom.d.gmai.com
All,
I am trying to get drag and drop working, from my own navigator view into
my diagram.
I extended DiagramDropTargetListener#getObjectsBeingDropped to return a
list of EObjects. These are made by calling my
EFactory.eINSTANCE.createXX(), then setting some properties. Then, I
realized I couldn't just use the DiagramDragDropEditPolicy to create the
views, since these objects weren't actually in the model, and that is what
that policy seems to expect. So I am using CreateViewAndElementRequest to
make a new object of the correct type, and now the dropped objects persist
in the diagram. However, the new object is not initialized with the
properties of the EObject I created in getObjectsBeingDropped. So based on
another post to this list, I extended AbstractTransactionalCommand with
this in the doExecuteWithResult method:
<code>
EObject newElement = (EObject)adapter.getAdapter(EObject.class);
Object newObject = newElement.eCrossReferences().get(0);
EcoreUtil.replace((EObject)newObject, replacement);
return null;
</code>
where 'adapter' is gotten from
CreateViewElementRequest#getViewAndElementDescriptor(), and 'replacement'
is the EObject I created in getObjectsBeingDropped. This seems to work
well, except that the dropped objects are getting placed to the right and
down a few pixels of each successively dropped object, making a stair-step
pattern as I drop objects. Is there some reason the transaction is
triggering some auto-layout? I am using
CreateViewAndElementRequest#setLocation, and this worked perfectly until I
added my AbstractTransactionalCommand.
Thanks for reading my long post,
Tom
|
|
|
| Re: EcoreUtil.replaceEObject() causes layout problem with dropped object [message #205239 is a reply to message #204289] |
Thu, 11 September 2008 11:16  |
 Tom D
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Tom D wrote:
...
> CreateViewElementRequest#getViewAndElementDescriptor(), and 'replacement'
> is the EObject I created in getObjectsBeingDropped. This seems to work
> well, except that the dropped objects are getting placed to the right and
> down a few pixels of each successively dropped object, making a stair-step
> pattern as I drop objects. Is there some reason the transaction is
> triggering some auto-layout? I am using
> CreateViewAndElementRequest#setLocation, and this worked perfectly until I
> added my AbstractTransactionalCommand.
I found that EcoreUtil.replace() removes the links that are made to the
notation model somehow, and so the views were being created by the
canonical policy when it found "new" semantic elements. There seems to be
a bug in XYLayoutEditPolicy that is making those views: it doesn't seem to
handle zooming well, and/or it is somehow getting the center of the canvas
instead of the center of the parent figure when it determines the center
point to insert the new views.
Instead I would like my custom CompositeTopDown layout provider to do the
layout. It seems to be called when these views are created, but it doesn't
actually do any layout work unless I select "Arrange All" from the menu. I
followed the "custom layout" instructions in the GMF tutorial, but I
wonder if there is some extra steps I need to follow?
Thanks,
Tom D
|
|
|
Powered by
FUDForum. Page generated in 0.03465 seconds
] 
Search
Help
Register
Login
Home
