Community
Participate
Working Groups
While investigating bug #332091 I found out that Display#setCursorLocation(Point) as well as Display#post(Event) with a mouse move event does not update cursor location on windows xp, while it does e.g. on macosx cocoa. You can use the following snippet to reproduce: package swt.bugs; import org.eclipse.draw2d.FigureCanvas; import org.eclipse.swt.SWT; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Event; import org.eclipse.swt.widgets.Listener; import org.eclipse.swt.widgets.Shell; public class BugXXX { private static final int STEP = 5; public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(); shell.setLayout(new FillLayout()); final FigureCanvas canvas = new FigureCanvas(shell); canvas.addListener(SWT.KeyDown, new Listener() { public void handleEvent(Event event) { Point l = display.getCursorLocation(); switch (event.keyCode) { case SWT.ARROW_DOWN: setCursorLocation(display, l.x, l.y + STEP); break; case SWT.ARROW_UP: setCursorLocation(display, l.x, l.y - STEP); break; case SWT.ARROW_RIGHT: setCursorLocation(display, l.x + STEP, l.y); break; case SWT.ARROW_LEFT: setCursorLocation(display, l.x - STEP, l.y); break; } } }); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { while (!display.readAndDispatch()) { display.sleep(); } } } protected static void setCursorLocation(Display display, int x, int y) { // display.setCursorLocation(x, y); Event event = new Event(); event.type = SWT.MouseMove; event.x = x; event.y = y; display.post(event); } } While the visible mouse cursor can be moved with the arrow keys under mac, it stays at its position under windows xp.
I noticed this also today whilst testing the GEF patch that this originates from. The mouse cursor not moving also happens (or rather, doesn't happen!?) on Windows 7 also.
They both (Display#post and Display#setCursorLocation() work for me on Windows 7 running SWT from HEAD. Note: in your snippet, I replaced the FigureCanvas by a org.eclipse.swt.widgets.Canvas. I ran the snippet and use the arrows keys, I saw the mouse cursor moving around just fine. For you, does it stay at the same position ?
(In reply to comment #2) > They both (Display#post and Display#setCursorLocation() work for me on Windows > 7 running SWT from HEAD. > > Note: in your snippet, I replaced the FigureCanvas by a > org.eclipse.swt.widgets.Canvas. > > I ran the snippet and use the arrows keys, I saw the mouse cursor moving around > just fine. For you, does it stay at the same position ? I also observed that it works with Windows 7. The problem occurs on Windows XP, where the cursor stays at the same position.
(In reply to comment #3) > I also observed that it works with Windows 7. The problem occurs on Windows XP, > where the cursor stays at the same position. worked for me (XP SP3). What version of SWT are testing ? make sure to try with HEAD.
(In reply to comment #4) > (In reply to comment #3) > > I also observed that it works with Windows 7. The problem occurs on Windows XP, > > where the cursor stays at the same position. > > worked for me (XP SP3). What version of SWT are testing ? make sure to try with > HEAD. I tried Eclipse 3.6.1 release build. I will check again using a 3.7 build.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I also observed that it works with Windows 7. The problem occurs on Windows XP, > > > where the cursor stays at the same position. > > > > worked for me (XP SP3). What version of SWT are testing ? make sure to try with > > HEAD. > > I tried Eclipse 3.6.1 release build. I will check again using a 3.7 build. I can still reproduce it on WinXP SP3 using 3.7M4. Now I will download the latest nightly build and check it there...
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > I also observed that it works with Windows 7. The problem occurs on Windows XP, > > > > where the cursor stays at the same position. > > > > > > worked for me (XP SP3). What version of SWT are testing ? make sure to try with > > > HEAD. > > > > I tried Eclipse 3.6.1 release build. I will check again using a 3.7 build. > > I can still reproduce it on WinXP SP3 using 3.7M4. Now I will download the > latest nightly build and check it there... And I can still reproduce it with the 3.7 N20101215-2000 win32.x86 nightly build. My XP version is a German Version 2002, SP 3). I am running it on a Parallels virtual machine on my Mac. Can't you reproduce it using this respective version?
(In reply to comment #7) > I am running it on a > Parallels virtual machine on my Mac. Can't you reproduce it using this > respective version? What is the SmartMouse option for the virtual machine set to? Parallels may be blocking the ability to move the cursor on you. (from the main menu, Virtual Machine -> Configure -> Advanced -> SmartMouse)
(In reply to comment #8) > (In reply to comment #7) > > I am running it on a > > Parallels virtual machine on my Mac. Can't you reproduce it using this > > respective version? > > What is the SmartMouse option for the virtual machine set to? Parallels may be > blocking the ability to move the cursor on you. (from the main menu, Virtual > Machine -> Configure -> Advanced -> SmartMouse) Scott, you are right, this seems to be the reason.
(In reply to comment #9) > > What is the SmartMouse option for the virtual machine set to? Parallels may be > > blocking the ability to move the cursor on you. (from the main menu, Virtual > > Machine -> Configure -> Advanced -> SmartMouse) > > Scott, you are right, this seems to be the reason. There's not much we can do about it, then. I think we can close this as invalid.
(In reply to comment #10) > (In reply to comment #9) > > > What is the SmartMouse option for the virtual machine set to? Parallels may be > > > blocking the ability to move the cursor on you. (from the main menu, Virtual > > > Machine -> Configure -> Advanced -> SmartMouse) > > > > Scott, you are right, this seems to be the reason. > > There's not much we can do about it, then. I think we can close this as > invalid. You are right. Nevertheless, thank you both for investigating this!
