Community
Participate
Working Groups
Eclipse 3.2 According to the JavaDoc of Control#setCapture(), "causes the receiver to have all mouse events delivered to it until the method is called with false". See this snippet: public class Main { static Tree t; public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Button b = new Button(shell, SWT.NONE); b.addSelectionListener(new SelectionAdapter() { public void widgetDefaultSelected(SelectionEvent e) { t.setCapture(true); } }); t = new Tree(shell, SWT.NONE); for (int i = 0; i < 100; i++) { new TreeItem(t, SWT.None).setText("Hello World"); } shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } } } Hitting the Button, I begin using my MouseWhell to scroll, but the Tree is not scrolling. From what the JavaDoc tells me, I had expected this behaviour. Since I more think that this is a platform-limitation than a bug in setCapture() , at least the JavaDoc should clarify what this API is about. Ben
Yes, Windows has the restriction that the mouse must be down for mouse capture to work. CAR, we should document this.
Also using Eclipse 3.2. So that you know, it would appear that this restriction is present for Macs as well. I found this bug report while I was looking to report on the same issue. I have code that should let the user click and drag within a composite and ONLY STOP dragging when the mouse button is released (even if the cursor has left the composite). Therefore I have mouseDown calling setCapture(true) and mouseUp calling setCapture(false). It works for the left mouse button, OR for any combination that INCLUDES the left button. But when using right button only, it does not continue to receive any mouse events when the cursor leaves the composite. So it must be the same issue, yes? I would appreciate if you would please document.
Sorry to spam, but I just noticed something you'd be much more interested in... I eliminated ALL my setCapture() commands and mouse moves are STILL being sent to my GLCanvas as long as I have the left button down. Mouse moves stop being sent as soon as I release the left button. THEN I ran a little experiment and found that it works this way for ANY control WHATSOEVER. I don't like that, but my intuition tells me this might be part of OS X's great drag-n-drop support, so perhaps it's a fair trade-off. No wonder my attached source shows only this: public void setCapture (boolean capture) { checkWidget(); } So anyway, does setCapture actually do something on Windows? Should I keep it in my app (which is supposed to be cross-platform)?
You don't need to call setCapture() when the mouse is pressed. On all platforms, there is an "automatic grab" when the mouse is pressed that lasts until the mouse is released. I could have sworn this was documented somewhere ... Carolyn? If not, we should fix the Javadoc. There is still a problem that Control.setCapture() doesn't work as documented on Windows and the Mac. We should fix the Javadoc (seeing as we can't work around the Windows behavior, even if we wanted to). Once the Javadoc is fixed, we can close this bug report.
Fixed > 20080429 Changed the Javadoc only.
