|Re: Common Navigator PluginTransfer DND [message #768097 is a reply to message #766959]
||Mon, 19 December 2011 15:17
| Erik Englund
Registered: July 2009
I'm not sure why this does not make sense to you. You are essentially modifying the Project Explorer to handle the drop of your object then your plugin is installed. I think this is the way things are supposed to work.
You are probably right. I just felt it was strange since I didn't want to contribute any content to the Project Explorer, I just wanted to contribute behavior. For example, I didn't want my Navigator content to appear in the Content Tab of the Project Explorer. But I still wanted be able to drag my content from my navigator into the project explorer.
Can you elaborate on the last sentence please? (Forgive me, I have been away from this code for a while, but I would like to understand if we need to do anything here).
Forgive me, I just read over it myself and realized I should have proof read it some more before submitting.
Basically, I saw my DropAdapterAssistant if I extend CommonDropAdapterAssistant I can override the following methods:
IStatus handlePluginDrop(IStructuredSelection, Object)
IStatus validatePluginTransferDrop(IStructuredSelection, Object)
They seemed to work the same way as the validateDrop and handleDrop methods, only these would be triggered by the callback of the PluginTransferData.
I assumed that meant if I dragged an item from my NavigatorContent onto another viewer it would use the PluginTransferData and callback to my DropAdapterAssistant.
While debuging it I saw that in the CommonDropAdapter.dragEnter(DropTargetEvent) it first checks to see if the event supports LocalSelectionTransfer. If it does it tries to handle the event as a LocalSelectionTransfer. Since I am dragging from a NavigatorContententViewer the LocalSelectionTransferType will always be supported as well as PluginTransferType.
Now I was hoping that the other viewer would realize it couldn't handle the object within the LocalSelectionTransfer and thus abort back to using the PluginTransferType instead. This doesn't appear to be the case. It appears the only way the PluginTransferData Type would be used is if the Event did NOT support either LocalSelectionTransferType nor FileTransferType.
Powered by FUDForum
. Page generated in 4.87167 seconds