Community
Participate
Working Groups
Build Identifier: M20090917-0800 In the Message Broker Toolkit, there are many places where Drag and Drop is being used, in all but one of those cases, drag and drop seems to work on all tested platforms. However, there is once case where drag and drop works on WindowsXP and also on Linux but does not work on Windows7. The source for the drag is an extension of TreeViewer, the target for the drop is an extension of SourceViewer. The same TreeViewer source can be used as a drag source when dropping to other locations, which tells me that the drag adapters are properly connected. The same SourceViewer drop target can be used as a target from other places also which indicates to me that the drop adapter is correctly attached. The problem transfer type is also the same in all these cases so I don't think that is factor. In the problem combination, the DropTargetListener never gets called at all, so it is not a problem with the validateDrop or anything like that. After posting this on the following forum, the response I got was that this is likely an SWT bug. http://www.eclipse.org/forums/index.php?t=rview&goto=537165#msg_537165If Reproducible: Always Steps to Reproduce: 1. Initiate drag from the TreeViewer control 2. Drag over the SourceViewer
Please provide more information. How can I reproduce this problem on my machine ? Does this problem happen in Eclipse ? Can you provided a snippet that reproduce the problem ?
It turns out that this is a result of a difference in when the focusGained events are sent on various platforms. In Windows XP, it seem that there is acutally a bug where the org.eclipse.swt.widgests.Control does not send a focusGained event when a drag starts. In my case, the mouse comes into the TreeViewer control, and rather than explicitly (mouseDown and mouseUp) selecting something, I just start dragging it (mouseDown only), no focusGained event is sent on Windows XP. However, on Linux, the fact that the drag started in the TreeViewer control does cause the focusGained event to be sent. I noticed this difference by examining the difference in Control.sendFocusEvent in both org.eclipse.swt.gtk.linux_x86_3.4.1.v3453a.jar and org.eclipse.swt.win32.w32.x86_3.4.1v3453a.jar Based on behaviour, I believe that the correct events are also being sent on Windows 7, thus it is only on Windows XP where the sequence is incorrect. That being said, I don't know if this is an SWT bug or a Windows XP bug.
Are you stuck ? Can you change your code so it works everywhere ? As for the focus being sent, this is a bit of a gray area. Platform specific in my opnion. Personally not changing the focus makes sense to me, specially when the drag operation is canceled (by pressing escape key during drag).
A snippet showing this difference is below. On Linux-GTK and Vista I see a FocusIn event when directly dragging its TreeItem, while on Windows 2000 and XP I don't see this event. I did not try Windows 7, but I assume it behaves like Vista. What's confusing is that the initial description indicated that Linux-GTK and XP were working and Windows 7 was not. However if it's believed that receiving this FocusIn event is required, then it seems like Linux-GTK and Windows 7 should be working and XP should be broken. Are you sure that this is what's needed? For instance, on whichever Windows platform is not working, can the problem case be made to work by first selecting the item to drag (ie.- mouseDown+mouseUp on it) to give focus to the Tree, and then initiate the drag? public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.setLayout(new GridLayout()); Text text = new Text(shell, SWT.SINGLE); text.setText("initial focus"); final Tree tree = new Tree(shell, SWT.BORDER); new TreeItem(tree, SWT.NONE).setText("drag me"); tree.addFocusListener(new FocusListener() { public void focusLost(FocusEvent e) { System.out.println("Tree focus out"); } public void focusGained(FocusEvent e) { System.out.println("Tree focus in"); } }); Transfer[] types = new Transfer[] {TextTransfer.getInstance()}; int operations = DND.DROP_MOVE | DND.DROP_COPY | DND.DROP_LINK; final DragSource source = new DragSource (tree, operations); source.setTransfer(types); final TreeItem[] dragSourceItem = new TreeItem[1]; source.addDragListener (new DragSourceListener () { public void dragStart(DragSourceEvent event) { TreeItem[] selection = tree.getSelection(); if (selection.length > 0) { event.doit = true; dragSourceItem[0] = selection[0]; } }; public void dragSetData (DragSourceEvent event) { event.data = dragSourceItem[0].getText(); } public void dragFinished(DragSourceEvent event) { if (event.detail == DND.DROP_MOVE) dragSourceItem[0].dispose(); dragSourceItem[0] = null; } }); shell.setSize (400, 400); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); }
Knowing that this was the issue with my drag an drop problem, I have resolved the problem by adjusting my code. I no longer need any fixes although it might still make sense to keep this difference in event sending for the record. To answer Grant's question, regarding why I said it worked on XP when that is actually where the focusGained is NOT sent, the reason for that is in my case, it was the absence of the event that was making it work, thus the bug in Windows XP made it work. So for the purpose of drag and drop, I have altered my code to perform the same regardless of where these events are sent and thus fixed my problem.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
