| EMF Drag and Drop [message #1750898] |
Sat, 31 December 2016 15:49  |
Eclipse User |
|
|
|
Hello,
I have 4 Trees and want to drag and drop items from one tree to another.
I looked at the emf generated editor code but I need something else.
The first treeview has a library which exposes the metamodel and the others have the actual EObjects. I like to drag and drop items from the metamodel to the other trees depending on the superclass in the metamodel. I added EditingDomainViewerDropAdapter and ViewerDragAdapter to all treeviews. Drag and drop works between all trees except the library with the metamodel. I need a way to create new instances on drop but don't know how to achieve this (DragAndDropCommand?)
I also like to know how to do a check (validateDrop) in each tree before the drop if the item is suitable. I used ViewerDropAdapter in the past but EditingDomainViewerDropAdapter seems not to have a feature like that.
Thanks
-Michael
|
|
|
| Re: EMF Drag and Drop [message #1751001 is a reply to message #1750898] |
Tue, 03 January 2017 10:20  |
| Eclipse User |
|
|
|
|
Mostly you can specialize drag and drop behavior by specializing the createXyzCommand methods in the generated XyzItemProvider of the receiver/target. If the created command is not executable, drag and drop will not be allowed. So you can specialize the org.eclipse.emf.edit.provider.ItemProviderAdapter.createAddCommand(EditingDomain, EObject, EStructuralFeature, Collection<?>, int) to either allow an add or to now allow it. In the case where you need to somehow convert what's dropped to something else, you can specialize org.eclipse.emf.edit.provider.ItemProviderAdapter.getChildFeature(Object, Object) on the receiver (which is called by org.eclipse.emf.edit.provider.ItemProviderAdapter.factorAddCommand(EditingDomain, CommandParameter)) so that it returns the appropriate feature where you want that object's converted result to be added, and then specialize the createAddCommand to filter the collection to convert the object to be added to some type of object that can really be added.
|
|
|
|
| Re: EMF Drag and Drop [message #1751638 is a reply to message #1751609] |
Thu, 12 January 2017 02:31 |
| Eclipse User |
|
|
|
Your observation on differences in drag and drop behavior is definitely an inherent difference in behavior of the platforms. Indeed generally there is no drag data available until the drop phase on Linux and Mac. EMF's implementation of LocalTransfer also has that behavior because it won't return the selected object until the transfer data returns the expected start time. You can use the platform's LocalSelectionTransfer to get different behavior, but keep in mind that all other transfers will similarly not have the drag data available early so if you're expecting that generally, it won't work generally. Only Windows provides this behavior.
In Oomph I worked on an improved (more flexible) implementation of drag and drop support for EMF (e.g., provide a textual transfer of the XMI serialization of the selection so that drag and drop works between separate processes, and using the system clipboard so that drag and drop generally works between editors, even in separate processes), but even here, the differences in platform behavior are super annoying. I.e., if I can't know the object being dragged, so I can't provide decent early feedback, and I can't even determine which is the best transfer to use based on the data that's available in the transfer. In this scenario, the behavior of checking the start time becomes more important, because the start time of the LocalTransfer will not match what's in the transfer data and hence the local selection that might be available shouldn't be used.
|
|
|
Powered by
FUDForum. Page generated in 0.03397 seconds
Home