Summary: | [Navigator] Exception occurs during drag file into Run-time workbench | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | SC Development 01 <scdev01> | ||||||
Component: | UI | Assignee: | Knut Radloff <knut_radloff> | ||||||
Status: | CLOSED FIXED | QA Contact: | |||||||
Severity: | major | ||||||||
Priority: | P1 | CC: | n.a.edgar, veronika_irvine, yasuday, ycpeng | ||||||
Version: | 2.1 | ||||||||
Target Milestone: | 2.1 M5 | ||||||||
Hardware: | Other | ||||||||
OS: | Linux-GTK | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
SC Development 01
2003-01-20 04:05:34 EST
Created attachment 3038 [details]
The sample project for the testing.
Created attachment 3039 [details]
The exception contents.
This is not a DBCS problem, this is a problem everywhere - adjusting title accordingly. The problem is that in a drag over, there is not always data available (there is on windows but not on any other platforms which is why the data is not in the event itself and you have to get yourself by a back doors means). As a result, the following code NavigatorDropAdapter.validateTarget is going to pass null into CopyFilesAndFoldersOperation.validateImportDestination which is not handled: if (FileTransfer.getInstance().isSupportedType(transferType)) { String[] sourceNames = (String[]) FileTransfer.getInstance().nativeToJava(transferType); CopyFilesAndFoldersOperation copyOperation = new CopyFilesAndFoldersOperation(getShell()); message = copyOperation.validateImportDestination (destination, sourceNames); } The NavigatorDropAdapter makes incorrect assumptions when it is detecting a viewer local drag operation. Need to change this to allow Eclipse local drag operations. Note that this PR describes a scenario where you are dragging between two different eclipse launches (i.e. not a local drag). This is why a FileTransfer comes into play. The ResourceTransfer includes a hashcode in the id that makes it unique to one eclipse launch. Yes, I'm still figuring out how JDT package explorer does the DND. It apparently uses a FileTransfer. Also, the ids don't seem to be unique on Linux. I looked into this a little bit. I'll just file a bug and leave it to you. Debugging DND on Linux is a pain. The ui locks up when a breakpoint is hit in e.g., dragEnter. How do you debug DND? System.out.println? *** Bug 29777 has been marked as a duplicate of this bug. *** Fixed in >20030126 I don't understand why we needed to add a new kind of local transfer. ResourceTransfer was already adding the system time to the registered type (see ResourceTransfer.TYPE_NAME) in an attempt to make it unique. Are you saying that it's still not unique due to bug 30210? I don't see how they can't be since the must be completely different strings. The new LocalSelectionTransfer stores the selection directly and does not marshall the selected resources like the ResourceTransfer does. This allows me to access the drop data during the dragEnter/dragOver/dropAccept event on all platforms. Normally the data is only available during the final drop event. Having access to the drop data before the drop allows me to give early drag feedback if the drop is not possible. There is a back door to get at the drop data prior to getting the drop event but it only works on Windows. Uniqueness (or lack thereof) of transfer types is a separate problem. LocalSelectionTransfer still has that same problem. It is possible that we would get unique IDs if the strings differed at the beginning and not at the end. If the time between Eclipse launches is large enough we seem to be getting unique ids. I tested it with build I20030129-linux-gtk, this problem has been fixed. |