"Locking key state" is the status of CapsLock, NumLock etc. keys on the keyboard. Implementing it clearly requires native code, but returning false would just mean the applications wouldn't "see" if those keys are "on". It's much better than throwing exception, I think.
Vasily -----Original Message----- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 1:44 PM To: [email protected] Subject: Re: [classlib][awt] Toolkit.getLockingKeyState() is not implemented Alexei Zakharov wrote: > I think if we can satisfy some programs just by returning false > without throwing any exceptions then this probably worth doing. In > other words, IMHO we can afford a single violation of our general rule > about NotImplementedException if it really improves usability of our > implementation. Thoughts? Sorry, I just meant that the method should be declared as throws the NotImplementedException as a marker to ourselves and JAPI, but now I go and look I can see that it already does. public boolean getLockingKeyState(int a0) throws UnsupportedOperationException, org.apache.harmony.luni.util.NotImplementedException { lockAWT(); try { } finally { unlockAWT(); } if (true) { throw new RuntimeException("Method is not implemented"); //TODO: implement //$NON-NLS-1$ } return true; } I don't know if returning 'false' is going to be a problem or not, since I have no idea what an "AWT Toolkit locking key state" is. Regards, Tim
