United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4942851 canImport should carry Transferable in TransferHandler
JDK-4942851 : canImport should carry Transferable in TransferHandler

Details
Type:
Enhancement
Submit Date:
2003-10-23
Status:
Resolved
Updated Date:
2005-06-22
Project Name:
JDK
Resolved Date:
2005-06-22
Component:
client-libs
OS:
windows_2000
Sub-Component:
javax.swing
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-25
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
                                     
2005-06-01



Hardware and Software, Engineered to Work Together