Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[Common Navigator][DnD] Non-deterministic drag behavior
https://www.eclipse.org/forums/index.php/mv/msg/275051/777166/#msg_777166
I extended the Project Explorer to show the content of zip files as
sub-items of the item that that represents the IFile. To be able to open
zip file entries by dragging them from the navigator to the editor area,
I implemented a CommonDragAdapterAssistant [1]. In setDragData(), it
wraps the given selection in an EditorInputTransfer to be processed by
the EditorAreaDropAdapter.
This doesn't always work though. I appended the trace output of a
successful [2] and an unsuccessful [3] drag operation below. An
unsuccessful attempt ends with a ClassCastException in the
EditorAreaDropAdapter [4].
The Project Explorer registers a ResourceDragAdapterAssistant. This
seems to somehow interfere with the CommonDragAdapterAssistant
implementation provided by me, though my assistant doesn't work with
resources.
As you can see from the traces, the most notable difference is the
"supported xfer type" while handling dragSetData(). In case the DnD
fails, this message isn't printed. But I'm unable to find out why the
transfer type does not match.
For completeness I provided the dragStart and validateDrop lines in the
trace, though I think they are related to drop events over the navigator
itself and irrelevant here.
[1] Sketch of CommonDragAdapterAssistant implementation
---
public class ArchiveDragAdapterAssistant
extends CommonDragAdapterAssistant {
public Transfer[] getSupportedTransferTypes() {
return new Transfer[] { EditorInputTransfer.getInstance() };
}
public void dragStart( DragSourceEvent event,
IStructuredSelection sel )
{
event.doit = false;
if( selection contains zip archive entry ) {
event.doit = true;
}
}
public boolean setDragData( DragSourceEvent event,
IStructuredSelection sel )
{
event.data = create EditorInputTransferData from given selection;
return true;
}
}
[4] Stacktrace
---
org.eclipse.swt.SWTException: Failed to execute runnable
(org.eclipse.core.runtime.AssertionFailedException: assertion failed: )
at org.eclipse.swt.SWT.error(SWT.java:4282)
at org.eclipse.swt.SWT.error(SWT.java:4197)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion
failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at
org.eclipse.ui.internal.ide.EditorAreaDropAdapter.asyncDrop(EditorAreaDropAdapter.java:116)
at
org.eclipse.ui.internal.ide.EditorAreaDropAdapter.access$0(EditorAreaDropAdapter.java:87)
at
org.eclipse.ui.internal.ide.EditorAreaDropAdapter$1.run(EditorAreaDropAdapter.java:81)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 23 more]]>Rüdiger Herrmann2012-01-10T00:37:59-00:00Re: [Common Navigator][DnD] Non-deterministic drag behavior
https://www.eclipse.org/forums/index.php/mv/msg/275051/777476/#msg_777476
In the successful attempt the event dataType is 51433, and in the failure it's 51476, which is causing the problem.
Hopefully this points you in the right direction, let me know if you need more help.
Francis Upton IV
Platform UI Committer
Common Navigator Framework http://oaklandsoftware.com]]>Francis Upton IV2012-01-10T15:16:16-00:00Re: [Common Navigator][DnD] Non-deterministic drag behavior
https://www.eclipse.org/forums/index.php/mv/msg/275051/778415/#msg_778415
thanks for the pointer. I can follow your reasoning with the
event.dataType. Only I cannot find who/where/when the dataType is
determined. The EditorAreaDropAdapter apparently doesn't do it. Can you
shed some light?
What also bugs me is that DnD works half of the times. If it works (or
doesn't), the behavior is stable until I restart the application.
Couldn't this be related to the order in which assistant extensions are
read/registered (only a wild guess)?
TIA
Rüdiger
------
On 10.01.2012 16:16, Francis Upton wrote:
The EditorInputTransfer type (used by your assistant) is not returning
true when asked isSupportedType(), have a look at that to see why (the
code to check is in its superclass ByteArrayTransferType). So you are
dragging some type that it cannot handle.
In the successful attempt the event dataType is 51433, and in the
failure it's 51476, which is causing the problem.
Hopefully this points you in the right direction, let me know if you
need more help.
Francis Upton IV
Platform UI Committer
Common Navigator Framework http://oaklandsoftware.com]]>Rüdiger Herrmann2012-01-11T17:34:29-00:00