Alex,
In EditingDomainViewerDropAdapter we have comments like this:
* This implementation of a drop target listener is
designed to turn a drag and drop
* operation into a {@link Command} based on the model objects
of an
* {@link EditingDomain} and created by {@link
DragAndDropCommand#create}. It is
* designed to do early data transfer so the the enablement
and feedback of the
* drag and drop interaction can intimately depend on the
state of the model objects
* involved. On some platforms, however, early data transfer
is not available, so this
* feedback cannot be provided.
and
/**
* This attempts to extract the drag source from the event
early, i.e.,
* before the drop method. This implementation tries to use a
* {@link org.eclipse.emf.edit.ui.dnd.LocalTransfer}. If the
data is not yet
* available (e.g. on platforms other than win32), it just
returns null.
*/
protected Collection<?> getDragSource(DropTargetEvent
event)
So yes, I'm pretty sure that you can't always get the dragged object
early to provide early feedback. Go figure that something so
fundamental would be poorly supported on some OSes, but SWT can't make
things the OS doesn't support well work anyway...
Alex Boyko wrote:
Hi,
Perhaps, I found the answer to my question. The event data field
contains the transfered data and in Linux this field is being set at
the drop time as opposed to Windows where the transfered data can be
obtained from the TransferData with a help of nativeToJava method
defined on the FileTransfer for example. Can someone confirm this
please?
So, there is no live feedback for the drop on Linux as far as i
understand, the only thing we have during the drag is the type of the
transfered data, right? So for FileTransfer, we'd only that it's a
file, but won't know exactly which file this is until it's dropped,
correct?
Thanks.
Cheers,
Alex
|