|
| Re: EMF Drag and Drop [message #1751001 is a reply to message #1750898] |
Tue, 03 January 2017 15:20   |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: EMF Drag and Drop [message #1751638 is a reply to message #1751609] |
Thu, 12 January 2017 07:31 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.05107 seconds
] 
Search
Help
Register
Login
Home
