Bugzilla – Full Text Bug Listing
| Summary: | [Fast Views] Drag from open Fastview to detached window causes problems | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Van Meekeren <michaelvanmeekeren> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | Grant Gayed <grant_gayed> |
| Severity: | normal | ||
| Priority: | P3 | CC: | dj.houghton, markus.kell.r, n.a.edgar, snorthov, sxenos, Tod_Creasey |
| Version: | 3.0 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Michael Van Meekeren
adding Tod to CC to test out a bug reported concerning JUnit view not redrawing This has been added to the list to stop ship for M8. According to Steve, this is due to an SWT bug in Tracker which they don't have time to fix for M8. We need a workaround. I tried leaving the view visible when starting a drag, but this has the unwanted side-effect of being able to drag overtop of an open fastview. I also tried disabling dragging from fastviews (just comment out the startDrag from the top of FastViewPane) -- this works, but makes it really hard to get rid of fast views. If we go this route, we should make sure we fix the missing "Fast View" contribution item. Leave as it is. Moving to M9 I have seen this one but it is quite hard to replicate. Since we are deferring this to M9, we aren't going to try to do a workaround and wait for a fix from SWT. Transferring this to SWT. This is a problem with setCapture(boolean), not Tracker. In the snippet at the
bottom, starting a drag within the Composite should not stop spewing integers
after the Composite is disposed 3 second later, but it does if the pointer is
not within the shell.
msdn states that if the pointer is outside of the capture widget's bounds then
mouse events are only delivered to the capture widget if the button was
originally pressed on the capture widget. It seems like pressing down on the
Composite in the example is considered to be close enough to pressing down on
the Shell, but once the Composite is disposed then the shell no longer
satisfies this criteria, and therefore only gets mouse events when the pointer
is over it.
public class Main {
static int counter=0;
public static void main (String [] args) {
final Display display = new Display();
final Shell shell = new Shell(display);
shell.setBounds(400,400,400,400);
final Composite composite = new Composite(shell, SWT.BORDER);
composite.setBounds(50,50,300,250);
composite.addListener(SWT.DragDetect, new Listener() {
public void handleEvent(Event event) {
shell.setCapture(true);
display.timerExec(3000, new Runnable() {
public void run() {
composite.dispose();
}
});
}
});
shell.addListener(SWT.MouseUp, new Listener() {
public void handleEvent(Event event) {
shell.setCapture(false);
}
});
shell.addListener(SWT.MouseMove, new Listener() {
public void handleEvent(Event event) {
System.out.println(counter++);
}
});
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
}
Stefan, I've looked at this with SN, and we're really unable to make Control.setCapture(...) work in this case. The msdn (link at bottom) states: " SetCapture captures mouse input ... when the mouse button was pressed while the mouse was over the capturing window and the button is still down. " However in this case the widget that got the original MouseDown (the fast view's CTabFolder) gets disposed right away, so saying controlUnderMousePointerAfterThisDispose.setCapture(true) does not satisfy the msdn criteria since this is a different widget than the fast view's CTabFolder. In the snippet that I included above I changed the composite.dispose() to composite.setVisible(false), and this made it work. So I suspect that a similar approach should work in your case as well. Are you able to do something like this at your level (ie.- hide the fast view initially, and then dispose it after the tracker is done, if needed)? SetCapture link: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/winui/WinUI/WindowsUserInterface/UserInput/MouseInput/MouseInputReference/Mou seInputFunctions/SetCapture.asp Hmm... yes, it should be possible to hide the CTabFolder rather than disposing it, if you think that will work. I'm curious why setCapture is relevant? The problem still occurs if you remove all calls to setCapture from our drag code. If setCapture was working properly then mouse events from outside of the workbench window would not be lost, since capture would be given to a valid widget. However, since setCapture is not working, the default capture behaviour should be relied upon. This will not deliver events from outside the workbench window once you have disposed of the widget that received the initial MouseDown (the CTabFolder in the fast view). But hiding this MouseDowned widget instead of disposing it should keep up the delivery of events from outside of the workbench window. Downgrading report because swt cannot make this work, and it seems that a ui- level workaround exists. Given the behavior described in the MSDN, I can't think of anything we can do to keep the mouse events coming other than not really disposing it when the guy calls dispose() and figuring when to really dispose it later. Given that the control may be an internal node in a tree of composites, the children would need to be disposed somehow and we would need to notice that the parent was disposed and not dispose the subtree. *** Bug 76977 has been marked as a duplicate of this bug. *** *** Bug 67561 has been marked as a duplicate of this bug. *** Moving report to triage, see http://www.eclipse.org/swt/triage.php for more info about swt bug handling. This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie. |