JDK-4217416 : DragSource.DefaultCopyDrop cursor does not work on windows 95/98/NT
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.2.0,1.2.2,1.2.2_005
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_98,windows_nt,windows_2000
  • CPU: x86
  • Submitted: 1999-03-04
  • Updated: 2001-05-04
  • Resolved: 2001-05-04
Related Reports
Duplicate :  
JDK-4245830 - DnD ACTION_COPY to JScrollPane shows "No Drop Target" cursor erroneously on NT
Duplicate :  
JDK-4451328 - 1.3.1 Regression: DnD Custom Cursors are Getting overridden by defaults
Duplicate :  
JDK-4349345 - Drag and Drop works, but cursor always indicate illegal operation
Description
When implementing dragEnter(DragSourceDragEvent dsde) of 
interface DragSourceListener, a call to
dsde.getDragSourceContext().setCursor(DragSource.DefaultCopyDrop);
fails to set the Cursor to a "drop" cursor on windows. 
It works fine on solaris.

The dnd operation executes fine, but the visual "drag over" 
feedback (cursor change) does not. This is an important bug 
that needs to be fixed.

=====
Reproducible test case is attached.
david.mendenhall@eng 2000-08-01
Comments
WORK AROUND The workaround is to not use DragSource.DefaultCopyDrop cursor. Using another cursor such as DragSource.DefaultMoveDrop works.
11-06-2004
EVALUATION ============================================================================= jethro@eng 11May99 This is a serious problem, but there is no time to fix it for kestrel. It will have to go into merlin. ============================================================================= Still reproducible in merlin build 25. david.mendenhall@eng 2000-08-01 Reproducible with 12Dec2000 AWT workspace. david.mendenhall@east 2000-12-13 The current implementation requires that you update the cursor in dragOver as well as dragEnter. We might be able to change this. If you don't update in dragOver, then the implementation falls back to the default cursor for the current operation. This cursor is computed by crossing the drag type with the drop acceptance type. The drag type is computed by looking at the keyboard modifiers held during the drag: No modifiers: Move Ctrl only: Copy Ctrl + Shift: Link The drop acceptance type is the same as the drag type unless the DropTargetListener explicitly calls acceptDrag with a *different* type. The DropTargetListener is free to bitwise-OR multiple types together. If the drag type bitwise-AND the drop acceptance type is non-zero, then the cursor will be set to the cursor from the drag type; otherwise, it will be set to the invalid drop cursor. This is not necessarilly desirable behavior, and I will need to think about this more. Also note that in Solaris the drag type must be computed differently; the implementation interprets the drag as a Copy, not a Move. david.mendenhall@east 2001-01-03 Name: dsR10078 Date: 05/04/2001 Actually the bug is reproducible on both Solaris and Windows depending on keyboard modifiers held during the drag: Win32 Solaris/Linux No modifiers: NoDrop DefaultCopyDrop Shift only: NoDrop NoDrop Ctrl only: DefaultCopyDrop DefaultCopyDrop Ctrl+Shift: NoDrop NoDrop The correct behavior is DefaultCopyDrop. The cause of this problem is that with the original implementation of custom drag cursors the drag cursor is reverted back to the default when the first drag notification arrives. This is clearly wrong. The same problem is documented under bug id 4451328. I verified that this bug is fixed with the fix for 4451328, so that the drag cursor is always set to DefaultCopyDrop. ###@###.### 2001-05-04 ======================================================================
04-05-2001