JDK-4942851 : canImport should carry Transferable in TransferHandler
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-10-23
  • Updated: 2005-06-22
  • Resolved: 2005-06-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b42Fixed
Related Reports
Duplicate :  
JDK-5029432 - Provide a way of getting the action in TransferHandler.importData(...)
Duplicate :  
JDK-5029427 - Location sensitive dropping
Relates :  
JDK-4378091 - Please add DropTargetDragEvent.getTransferable() method
Relates :  
JDK-4468566 - Swing DnD should not use selection to show drop location
Relates :  
JDK-6184817 - Make BasicDropTargetListener public
Relates :  
JDK-4760426 - JTree DnD conflicts with JTree.setUI(..)
Relates :  
JDK-6277499 - Minor API changes to support new Swing DnD API
Relates :  
JDK-5018712 - NO WAY TO TELL WHAT IS BEING DRAGGED UNTIL DROP OCCURS
Relates :  
JDK-6184866 - BasicTreeUI should use factory method to construct drop target listener
Description

Name: rmT116609			Date: 10/23/2003


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :

Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Implemeting more fine grained canImport functionality in
for structures like trees using TransferHandler is not
posible cause of limitation of arguments in

public boolean canImport(JComponent comp, DataFlavor[]
transferFlavors);

  To do checks to prevent moving child to its parent or
parent to its child should be possible. If canImport would
carry Transferable instead of DataFlavours it would make it
possible to do such checks and give more feedback to user !

Somtimes it is not enought to only know the datatype to be
imported.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
Write your completely own TransferHandler. Of Course.
(Incident Review ID: 181502) 
======================================================================
Comments
EVALUATION Name: agR10216 Date: 10/24/2003 This is a Swing rfe. Reassigning to classes_swing. ###@###.### 2003-10-24 ====================================================================== I completely agree. I've often thought that canImport(JComponent c, Transferable t) would be more useful than the current signature. In addition to what's mentioned in this bug report, it would allow canImport to do something like, boolean b = t.isDataFlavorSupported(myFlavor) to see if the Transferable supports the flavor we need. In some cases, this is nicer than looping through all of the Transferable's flavors as we do now. This request is definitely worthy of more investigation. ###@###.### 2003-10-28 Fixing this would require that drag&drop first fix 5018712. ###@###.### 2004-03-23 Okay, looks like 5018712 has already been fixed under another bug number - 4378091. So, looks like all of the drag&drop support we need is now in place. ###@###.### 2004-03-23 New API has been added to address this request. It was fixed together with 4468566. Here's what has been done: An overloaded version of canImport has been added that takes a new TransferHandler.TransferInfo object, containing many details about the current transfer. Developers should override this new method rather than the existing one. TransferInfo contains the following public methods for the user to query about the transfer taking place: boolean isDrop() JComponent getComponent() int getDropAction() DataFlavor[] getDataFlavors() boolean isDataFlavorSupported(DataFlavor df) Transferable getTransferable() DropLocation getDropLocation() The last method, getDropLocation() returns an object encapsulating the drop location, which minimally contains a Point object, but for some components a subclass will be provided containing more details about the location. See 4468566 for more details. In addition, two other methods have been overloaded to take a TransferInfo parameter: Normally, when canImport returns false, the drop location is not indicated visually in the component. Developers can change this behavior by overridding the following method: boolean shouldIndicateAnyway(TransferHandler.TransferInfo) The final overloaded method is: boolean importData(TransferHandler.TransferInfo) It should now be used instead of the old version of importData(). Together, these three methods give the developer a very powerful way to control what can and cannot be imported into the component. ###@###.### 2005-06-01 17:04:51 GMT
01-06-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
25-09-2004