JDK-4710682 : Drag from Java to Wordpad doesn't work correctly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt,windows_xp
  • CPU: x86
  • Submitted: 2002-07-03
  • Updated: 2006-08-31
  • Resolved: 2006-08-31
Related Reports
Duplicate :  
JDK-4869264 - drag & drop action negotiation does not honor the targets supported actions
Description
Name: dk106046			Date: 07/03/2002

1.4.1-beta-b04

If you open up a Windows WordPad application window alongside the Java Stylepad demo and drag something from Stylepad to Wordpad you will see that the cursor changes to a no entry symbol which implies that you cannot drop onto Wordpad. However, if you do drop over Wordpad it works fine.  The no entry symbol should not be shown.

======================================================================
Comments
EVALUATION This was fixed by 4869264.
31-08-2006
EVALUATION Reassigning to drag&drop. ###@###.### 2002-07-07 Name: dsR10078 Date: 07/09/2002 When an application initiates a drag operation it must specify which drop actions ("copy", "move" or "link") are supported for this operation. During drag the native DnD subsystem sends drag notifications to the drop target that is currently under the mouse cursor. These notifications report the actions supported by the drag source. In response to a drag notification the drop target should select one of the actions supported by the drag source and report it to the native DnD subsystem. Then the native DnD subsystem sends a drag notification to the drag source and passes the action selected by the drop target. The drag source determines the drop action selected by user based on the keyboard modifier state. The current implementation maps modifiers to drop actions as follows: Shift -> "move", Ctrl -> "copy", Ctrl+Shift -> "link". If no modifiers are pressed the set of drop actions supported by the drag source is searched for "move", "copy", "link" (in this order) and the first found action is considered the drop action selected by the user. If the application doesn't set the drag cursor explicitly, the drag cursor is updated by the drag source based on the intersection of the drop actions selected by the drop target and by the user. By default Swing drag sources support "copy" and "move" actions. Wordpad's drop target selects "copy" action. If no modifier keys are pressed, the current implementation determines that the user selects "move" action. As a result the drop actions selected by the drop target and by the user do not match. This results in "no entry" drag cursor. ###@###.### 2002-07-09 ====================================================================== Based on this evaluation, the submitter wishes to know if this explanation covers why the text is actually copied ok to the target even though the cursor said no entry? The submitter thought that a no entry cursor really meant no entry. ###@###.### 2002-07-17 ====================================================================== Name: dsR10078 Date: 07/17/2002 The drag cursor is set by the drag source based on the drop target response and on the keyboard modifiers state. Setting the drag cursor doesn't affect the state of the DnD operation. We can set any image as a drag cursor. In this case the current implementation chooses the drag cursor inappropriately that leads to counterintuitive results. ###@###.### 2002-07-17 ====================================================================== This bug will be fixed along with 4869264: drag & drop action negotiation does not honor the targets supported actions ###@###.### 2004-08-17
17-08-2004