Question

I have a mouse listener. It has some code to respond to mouseUp and mouseDown events. This works correctly.

However, as soon as I add a DragSource, my mouseDown event is no longer delivered — until I release the mouse button!

This is trivial to reproduce – below is a simple program which contains a plain shell with just a mouse listener and a drag listener. When I run this (on a Mac), and I press and hold the mouse button, nothing happens – but as soon as I release the mouse button, I instantly see both the mouse down and mouse up events delivered. If I comment out the drag source, then the mouse events are delivered the way they should be.

I’ve searched for others with similar problems, and the closest I’ve found to an explanation is this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=26605#c16
“If you hook drag detect, the operating system needs to eat mouse events until it determines that you have either dragged or not.”

However, I don’t understand why that’s true — why must the operating system eat mouse events to determine if I have a drag or not? The drag doesn’t start until I have a mouse -move- event with the button pressed.

More importantly: Can anyone suggest a workaround? (I tried dynamically adding and removing my drag source when the mouse is pressed, but then I couldn’t get drag & drop to function properly since it never saw the initial key press – and I can’t find a way to programmatically initiate a drag.)

Here’s the sample program:

    package swttest;

    import org.eclipse.swt.dnd.DND;
    import org.eclipse.swt.dnd.DragSource;
    import org.eclipse.swt.dnd.DragSourceEvent;
    import org.eclipse.swt.dnd.DragSourceListener;
    import org.eclipse.swt.events.MouseEvent;
    import org.eclipse.swt.events.MouseListener;
    import org.eclipse.swt.widgets.Display;
    import org.eclipse.swt.widgets.Shell;

    public class SwtTest {
        public static void main(String[] args) {
            final Display display = new Display();
            final Shell shell = new Shell(display);
            shell.addMouseListener(new MouseListener() {
                public void mouseUp(MouseEvent e) {
                    System.out.println("mouseUp");
                }

                public void mouseDown(MouseEvent e) {
                    System.out.println("mouseDown");
                }

                public void mouseDoubleClick(MouseEvent e) {
                    System.out.println("mouseDoubleClick");
                }
            });
            DragSourceListener dragListener = new DragSourceListener() {

                public void dragFinished(DragSourceEvent event) {
                    System.out.println("dragFinished");

                }

                public void dragSetData(DragSourceEvent event) {
                    System.out.println("dragSetData");

                }

                public void dragStart(DragSourceEvent event) {
                    System.out.println("dragStart");
                }
            };
            DragSource dragSource = new DragSource(shell, DND.DROP_COPY | DND.DROP_MOVE);
            dragSource.addDragListener(dragListener);
            shell.pack();
            shell.open();
            while (!shell.isDisposed()) {
                if (!display.readAndDispatch())
                    display.sleep();
            }
            display.dispose();
        }
    }

Answer 1

To answer your specific question about why this happens — on Cocoa we don’t consider a drag to have started until the mouse has moved a few pixels. This ensures against ‘accidental’ drags if you’re sloppy with the clicks. On Linux and Win32 the window toolkit can do the drag detection. If you just hold down the button the detection times out and the mouse down is delivered. On Cocoa we have no time out, which is why nothing happens until the drag is detected or a mouse up happens.

That’s a lot of detail, but the conclusion is that the behavior is inconsistent, and we should always be able to deliver the mouse down immediately, without waiting for the drag detection to complete.

I don’t see a workaround, since this is happening before the Control sees the event.

See this bug which has patches for win32, gtk and cocoa SWT.