Apache OpenOffice (AOO) Bugzilla – Issue 96915
CAPS LOCK LIGHT on keyboard
Last modified: 2009-01-14 15:13:38 UTC
There is a problem with the CAPS LOCK light on the keyboard. Under normal conditions, the CAPS LOCK light on the keyboard should be in the same state as the CAPS LOCK mode... CAPS LOCK light off = keyboard in lowercase. CAPS LOCK light on = keyboard in UPPERCASE. To replicate the problem, use a blank WRITER document try to enter text in CAPS as in the following example: "eXTREME " (you need to press the shift key for the first "e" as if you were not aware that the CAPS LOCK was on". As soon as you key in a "SPACE" OOWriter changes the word automatically to "Extreme " but fails to change the corresponding CAPS LOCK light on the keyboard. From this point on, the CAPS LOCK light on the keyboard is showing the reverse state, as if the keyboard was in CAPS LOCK mode, when in reality it is not. To re-synchronize the light with the CAPS LOCK mode, one has to reproduce the problem by writing "eXTREME" to have OOWriter correct the text once more.
I just checked and the problem also occurs in CALC, IMPRESS and DRAW so this may not necessarily be a WRITER code problem.
Please read the the help about "AutoCorrect" or "AutoFormat". Else, OOo is an Office Software and as such has/can't have/doesn't want to have any influence on your keyboard's LEDs!
closed
That issue should NOT be closed. Of course there is a problem, as described. When OOffice changes typing (autocorrect) from caps to small, constantly, it SHOULD change the caps light. That happens by calling the underlying system. It is not a matter of ASM coding or keyboard driver, it's just a DBus message or whatever, as it is for creating a form or opening the file dialog. For the opening files dialog, you wouldn't say "has/can't have/doesn't want to have any influence on your file system" , would you ? In order to help, I found a piece of java and another windows code that do the thing from common applications. For win: http://forum.soft32.com/win4/Start-program-caps-lock-ftopict193255.html Set objShell = WScript.CreateObject("WScript.Shell") objShell.SendKeys "{CAPSLOCK}" For java please see the "boolean capslock(boolean b)" method in: http://www.dreamincode.net/code/snippet1287.htm I hope that helps.
I think you talk about: https://bugs.freedesktop.org/show_bug.cgi?id=16145 As stated in: http://www.openoffice.org/issues/show_bug.cgi?id=62234 But the decription here says "As soon as you key in a "SPACE" OOWriter changes the word automatically to "Extreme " but fails to change the corresponding CAPS LOCK light on the keyboard." And there is no and should be no relation between a change in text format and the input state of the keyboard. That's why this issue is invalid.
Thanks for the reference. By the way, the xorg bug is considered fixed now (from 2008-11-22). Does it mean that with next xorg we will see it corrected? But, I fail to see the difference. If I get it correct, you propose that the case change (like in eXTREME to Extreme) should not be followed by a change in the keyboard (CapsLock) status, is that right? However, that was a required change and it is actually a logical one. That's why people took care of it in #62234. I thing the problem is not that the letter case is changed in eXTREME, nor that the CapsLock status changes to OFF (as it was asked in #62234). It is that changing the CapsLock status does not affect the CapsLock light.