Community
Participate
Working Groups
I have a simple example that reproduces a problem I am having. MouseDown normally occurs immediately. However, if the Control has a DragSource on it, the Drag starts, continues and completes all without the Mouse Down occuring, then, at the end of the Native DND operation, the Mouse Down event gets fired. It appears that Control{ ... LRESULT WM_LBUTTONDOWN (int wParam, int lParam) { sendMouseEvent (SWT.MouseDown, 1, OS.WM_LBUTTONDOWN, wParam, lParam); ... } sendMouseEvent does not happen synchronously. Instead, it posts an event which gets dispatched later, and in the next few lines of WM_LBUTTONDOWN, the drag notifications get sent. Here is the test case, which prints to the console the events: import org.eclipse.swt.SWT; import org.eclipse.swt.dnd.*; import org.eclipse.swt.events.*; import org.eclipse.swt.graphics.Color; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class SwtDndTest { public static void main(String[] args) { new SwtDndTest().run(); } public void createContents(Composite parent) { parent.setBackground(new Color(null, 128, 128, 128)); GridLayout gridLayout; gridLayout = new GridLayout(); gridLayout.numColumns = 2; gridLayout.marginHeight = gridLayout.marginWidth = 10; parent.setLayout(gridLayout); // Create the left Canvas GridData gridData = new GridData(GridData.FILL_BOTH); Canvas lCanvas = new Canvas(parent, SWT.NONE); lCanvas.setLayoutData(gridData); lCanvas.setBackground(new Color(null, 255, 255, 255)); // Add a mouse listener to the left Canvas lCanvas.addMouseListener(new MouseAdapter() { public void mouseDown(MouseEvent event) { System.out.println("Mouse Down"); } public void mouseUp(MouseEvent event) { System.out.println("Mouse Up"); } }); // Setup the left Canvas to have a DragSource DragSource dragSource = new DragSource(lCanvas, DND.DROP_MOVE | DND.DROP_COPY | DND.DROP_LINK); dragSource.setTransfer(new Transfer[] { TextTransfer.getInstance() }); dragSource.addDragListener(new DragSourceAdapter() { public void dragStart(DragSourceEvent event) { System.out.println("Drag Start"); } }); // Create the right Canvas gridData = new GridData(GridData.FILL_BOTH); Canvas rCanvas = new Canvas(parent, SWT.NONE); rCanvas.setLayoutData(gridData); rCanvas.setBackground(new Color(null, 255, 255, 255)); // Setup the right Canvas to have a DropTarget DropTarget dropTarget = new DropTarget(rCanvas, DND.DROP_MOVE | DND.DROP_COPY); dropTarget.setTransfer(new Transfer[] { TextTransfer.getInstance() }); dropTarget.addDropListener(new DropTargetAdapter() { public void drop(DropTargetEvent event) { System.out.println("Drop"); } }); } public void run() { Display display = new Display(); Shell shell = new Shell(display); createContents(shell); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
I'm pretty sure this is a duplicate PR, but the test case is good. Thanks.
Possible solutions involve posting DragDetect or running the defered events before sending the DragDetect. VI, wasn't there another PR involving event ordering and DragDetect where we decided what the correct thing to do was?
It was not that sendEvent isn't a real send but rather that starting a DND operation on Windows does not return until the DND operation is finished. The fix was to post the DragDetect event.
ButtonDown does not get sent quickly enough. If I press the button and don't release it, I don't get the down event until the DND histeresis has elapsed. This will make our application appear sluggish when the user expects to see immediate feedback when the press the button.
Why are you using mouse down. Why do you not use the Selection event for the button. What is it you are trying to do?
The user is clicking on a Canvas. The user should see immediate feedback such as Selection handles or a "simulated" focus rectangle, or a simulated button pressing down. We can only show these things if the MouseDown happens immediately.
Any updates on when and if this might be fixed? This is affecting our ability to create a palette from which the user can drag stuff using native DND.
JJ and GA have asked for Native Drag from the GEF palette for WSADIE, which is based on 2.0.x. The fact that mouse-down is delayed will mean that scrolling "drawers" in the palette will be very difficult. Typically, the user will press and hold down the mouse button on a a down arrow (which is just a lightweight figure in our case) and expect continued scrolling. We will have a .5 second pause because the mouse down doesn't come for approximately that long.
VI to investigate effect of reordering of send MouseDown and DragDetect on all platforms.
I don't understand that last comment. The ordering is now correct to me the client (meaning mouse down occurs, and then DragStart after). The only problem to me is the timing. Mouse down doesn't happen for about 400 ms. Maybe your comment was regarding some implemenation details that are over my head.
The comment is with regard to the implementation detail. It is the call to OS.DragDetect that does not return immediately and is causing the delay you observe.
I don't understand the OS.dragDetect stuff. But to me it sounds like SWT needs to send a fake MouseDown event prior to calling OS.dragDetect. Does this sound like the solution? Can you update the target milestone, I still consider this part of the same problem (dragStart vs. mouseDown timing).
On GTK, mouse down occurs faster than on windows.
win32 is the only platform on which mouseDown is delayed, and it is the only platform on which dragStart happens after a given amount of time, rather than when the user drags the mouse past a certain threshold. Can either of these be addressed?
Moving to Steve. I don't think anything can be done about this. The delay is part of the OS call to check for drag detect.
This happens because the platform runs a modal loop to determine whether a drag has occurred. During that modal loop, it can't send events because application code could run that could change the state of the widget. For example, in a text control, text might get selected. We WONTFIX this.
I actually thought this had been fixed already.
