JDK-7015209 : Shift+arrrow does not work on windows 7.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u23
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2011-01-27
  • Updated: 2011-02-02
  • Resolved: 2011-02-02
Related Reports
Duplicate :  
JDK-4838497 - Robot.keyPress(KeyEvent.VK_RIGHT) always types Numpad right arrow key
Description
Windows 7 Professional 64
Lenovo T410 laptop

Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)

Next code does not select the last char:

        JFrame frm = new JFrame();
        frm.getContentPane().add(new JTextField("some text"));
        frm.setSize(200, 200);
        frm.setVisible(true);
        new Thread(new Runnable() {
            public void run() {
                try {
                    try {
                        Thread.sleep(6000);
                    } catch (InterruptedException ex) {
                    }
                    Robot robot = new Robot();
                    robot.keyPress(java.awt.event.KeyEvent.VK_END);
                    robot.keyRelease(java.awt.event.KeyEvent.VK_END);
                    robot.keyPress(java.awt.event.KeyEvent.VK_SHIFT);
                    robot.keyPress(java.awt.event.KeyEvent.VK_LEFT);
                    robot.keyRelease(java.awt.event.KeyEvent.VK_LEFT);
                    robot.keyRelease(java.awt.event.KeyEvent.VK_SHIFT);
                } catch (AWTException ex) {
                    ex.printStackTrace();
                }
            }
        }).start();

Works fine on linux and windows versions other than 7.
Comments
EVALUATION Closed as a duplicate of 4838497 Robot.keyPress(KeyEvent.VK_RIGHT) always types Numpad right arrow key
02-02-2011
WORK AROUND Turn off numlock. if it's enabled, then robot.pressKey(arrow) synthesizes numpad's arrow key.
01-02-2011
EVALUATION AWT's Robot synthesizes keystrokes using the keybd_event API. One of the parameters of the keybd_event function is the dwFlags parameter and the use of the parameter is: KEYEVENTF_EXTENDEDKEY - If specified, the scan code was preceded by a prefix byte having the value 0xE0 (224). KEYEVENTF_KEYUP - If specified, the key is being released. If not specified, the key is being depressed. If a key is released by robot, AWT sets the dwFlags to KEYEVENTF_KEYUP. If a key is pressed by robot, AWT sets the dwFlags to zero. In other words, AWT never simulates correctly an *extended key* press/release (including non-Numpad arrow keys). This seems to the root cause of the problem. Additional information: here's the flow of events I observe when running the test: - press VK_END => simulates WM_KEYDOWN (End) - release VK_END => simulates WM_KEYUP (End) - press VK_SHIFT => simulates WM_KEYDOWN (Shift) - press VK_LEFT => simulates WM_KEYUP (Shift) (*) => simulates WM_DOWN (Left) - release VK_LEFT => simulates WM_KEYUP (Left) => simulates WM_KEYDOWN (Shift) (*) - release VK_SHIFT => simulates WM_KEYUP (Shift) The events marked by (*) seems to be incorrect and are generated unexpectedly. Looks like the system automatically releases (and later depresses again) the SHIFT key after any of the arrow key (an extended key) is simulated. Based on my investigations: 1. Windows7 - After applying the patch (when AWT sets the dwFlags to |KEYEVENTF_EXTENDEDKEY), i don't observe any unexpected SHIFT event (marked by (*)) anymore and the test works OK. 2. WinXP - The unexpected SHIFT events aren't generated in both cases - either KEYEVENTF_EXTENDEDKEY is specified for the extended keys or not. Seems like this bug can be considered as a misuse of the keybd_event API. In addition, the keybd_event API is deprecated now (MSDN: "This function has been superseded. Use SendInput instead."), It's better to re-implement this functionality (using SendInput) first and verify if the shift+arrow problem is gone.
27-01-2011