Community
Participate
Working Groups
If I have two resources A and B open in their editors, and I try to drag A into B from the navigator view, I cannot. The navigator will flip the active active editor to A, making it impossible to drop on B. It is possible to avoid this by checking the dragsourceevent.doit value during the dragStart callback, and storing this value until the drag finished callback has occurred. If it is true, then a native drag is about to start. The mousedown or selection event should come after the dragStart event, and "Link navigator selection to active Editor" can be suppressed.
I think I was wrong about event order. I believe MouseDown, and also Selection events will both fire before DragStart. Good luck.
I don't think the editors are even drop targets. What do you envision dropping a resource into an editor should do? Append the contents or replace it? We could support this by making a drag over the editor tab switch to that editor. I doubt this feature is particularly useful though. Marking as won't fix.
How do you know if Editor's are drop targets? *TONS* of editors are drop targets in WSAD. For example, dragging a .GIF file into a web page creates an <IMG> tag with that .GIF file. Or dragging another HTML file into an HTML file might create a link.
We should make the editor tabs drop targets then and check if the editor would accept the drop operation if possible.
> We should make the editor tabs drop targets then and check if the editor > would accept the drop operation if possible. Are you saying that it is impossible to avoid flipping pages, and you recommend this as a workaround to get back to the correct page? I agree that EditorPane and probably stacked views (and maybe the shortcut bar) should all flip to the appropriate tab/perspective/quickview for drag and drop support, but this is a separate bug. The issue of this bug is that the User's context is lost when they try to drag a resource from the Navigator View. The Navigator will flip Editors even though the user did not desire to open that resource.
Editors are switched on mouse up so it should be possible to avoid switching.
*** Bug 26105 has been marked as a duplicate of this bug. ***
Randy is correct, the Selection event is sent before DragStart. When the selection event is received we can run the linking part of the selection handling asynchronously to wait for the drag event. When the async runs the drag will have been noted by the navigator and the linking will be ignored. This is not elegant but it's also not horrible and would fix the problem with low impact. The alternative would be for SWT to send the drag event before sending the selection event. Changing event order is a bad idea and is not feasible.
What about waiting for mouseUp event? mouseUp events never occur once native DND begins.
I'm using DragDetect now which is more explicit than MouseUp for this scenario. I released a fix to HEAD on the 16th.
Verified in R2.1.3RC2 on MOTIF. Dragging file A does not cause the editor for A to come to focus before starting or during the drag.
Verified that this is fixed in the Navigator on Windows 2000 using 2.1.3RC2. Problem still occurs in the Package Explorer though. Is this needed for 2.1.3?
verified on mac on 2.1.3 RC2. problem doesn't occur on navigator or package explorer for me. (package explorer does throw up a very quick dialog - 'in progress', or something - on drop, but doesn't activate the other editor)
