harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasily Zakharov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4423) [classlib][awt][jedit] Toolkit.getLockingKeyState() is not implemented
Date Thu, 26 Jul 2007 14:22:40 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515710
] 

Vasily Zakharov commented on HARMONY-4423:
------------------------------------------

I've checked the behavior of Toolkit.getLockingKeyState()/setLockingState() on Windows XP
on RI and found that those methods work weirdly.

Here's a simple test demonstrating RI behavior:

import java.awt.Toolkit;
import java.awt.event.KeyEvent;
public class Test {
    public static void main(String[] args) {
        try {
            Toolkit toolkit = Toolkit.getDefaultToolkit();
            System.out.println("" + toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK)
                            + " " + toolkit.getLockingKeyState(KeyEvent.VK_NUM_LOCK)
                            + " " + toolkit.getLockingKeyState(KeyEvent.VK_SCROLL_LOCK)
                            /*+ " " + toolkit.getLockingKeyState(KeyEvent.VK_KANA_LOCK)*/);
// throws UnsupportedOperationException
            System.out.println("1. Turning CapsLock ON");
            toolkit.setLockingKeyState(KeyEvent.VK_CAPS_LOCK, true);
            Thread.sleep(1000);
            System.out.println(toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK));
            System.out.println("2. Turning CapsLock OFF");
            toolkit.setLockingKeyState(KeyEvent.VK_CAPS_LOCK, false);
            Thread.sleep(1000);
            System.out.println(toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK));
            System.out.println("3. Turning CapsLock ON");
            toolkit.setLockingKeyState(KeyEvent.VK_CAPS_LOCK, true);
            Thread.sleep(1000);
            System.out.println(toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK));
            System.out.println("4. Turning CapsLock OFF");
            toolkit.setLockingKeyState(KeyEvent.VK_CAPS_LOCK, false);
            Thread.sleep(1000);
            System.out.println(toolkit.getLockingKeyState(KeyEvent.VK_CAPS_LOCK));
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
}

If CapsLock was OFF at the application start, the output is as follows (comments denote what
happens at that point on the keyboard):

false true false
1. Turning CapsLock ON   // Light goes ON
false
2. Turning CapsLock OFF
false
3. Turning CapsLock ON   // Light goes OFF
false
4. Turning CapsLock OFF
false

If start CapsLock was ON at the application, the ouput is as follows:

true true false
1. Turning CapsLock ON   // Light goes OFF
true
2. Turning CapsLock OFF
true
3. Turning CapsLock ON   // Light goes ON
true
4. Turning CapsLock OFF
true

In other words, the following statements seem true about the RI operation:

- getLockingKeyState() returns the state of the key at the application start, calls to setLockingKeyState()
and pressing the key on the keyboard do not affect it.

- If the key was OFF at the application start, setLockingKeyState(false) does nothing, and
setLockingKeyState(true) toggles the actual state (light on the keyboard changes state and
typing (in other window) indicates the state changes immediately).

- If the key was ON at the application start, setLockingKeyState(true) does nothing, and setLockingKeyState(false)
toggles the actual state.

This behavior clearly contradicts the specification, but I suspect it's grounded by some Windows
API peculiarities.

I'm not sure if we should follow specification or RI behavior, but investigation of Windows
API capabilities in this area is surely required before we could make the right decision.


> [classlib][awt][jedit] Toolkit.getLockingKeyState() is not implemented
> ----------------------------------------------------------------------
>
>                 Key: HARMONY-4423
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4423
>             Project: Harmony
>          Issue Type: Bug
>          Components: App-Oriented Bug Reports, Classlib
>            Reporter: Vasily Zakharov
>            Assignee: Alexei Zakharov
>         Attachments: Harmony-4423-Workaround.patch
>
>
> Method java.awt.Toolkit.getLockingKeyState(int) is not implemented and throws RuntimeException
when called. This prevents some applications like jEdit automated GUI test scenario from running
normally, see HARMONY-3633, it had to provide a special workaround patch to address this issue.
> Implementing this method may be tough as it requires writing native code, however a simple
workaround patch may be created to improve compatibility while the real implementation is
absent. Here I provide this patch (actually extracted from HARMONY-3633) and my suggestion
is to apply it immediately.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message