Community
Participate
Working Groups
Reporter: Tiffany Language: Korean / Simplfied Chinese / Tranditional Chinese Build driver: eclipse-SDK-M4-linux-gtk OS: RedHat 8 JDK Ver.: IBM JDK1.3.1 + SR3 Test case #: 3.8 Using Content assist with DBCS strings Summary: DBCS: Exception occurs during drag file into Run-time workbench Steps to recreate problem: 1. Unzip the attachment (sef.zip) 2. Launch workbench with gtk build. 3. Import the plug-in com.ibm.wsweducation.solution.sef 4. Open the PDE perspective, then Select the project name. 5. Click Run icon > Run AS... > Run-time Workbench. 6. Run-time workbench pops up. 7. Create a Java project and a folder in the project in Run-time workbench. 8. Open the "Resource Perspective" in Run-time workbench. 9. Grab the test.release file in the original workbench then drag it into the folder which was created at step 7 in Run-time workbench. <<Error>> After step 9, some error messages were displayed in Console Window of the original Workbench Please refer the attachment (Exception.txt) NOTE: At step 8, if I open the "Java Perspective" in Run-time Workbench. The test.release file could be dragged into Run-time Workbench successfully without any error messages. <<Expected Result>> The test.release file should be draged into the folder in the "Resource Perspective" of Run-time workbench successfully without any error messages.
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?
SWT DND bug is bug 30210
*** 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.
