Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Turn lights on and off with Java

 
Peter Klotz
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
I am brandnew to the JavaRanch and first want to say Hello:
"Hello"

Maybe some one can help me with this questions:

I want to get the state of the 3 "lock"-lights on the keybord
(NumLock,CapsLock,ScrollLock)
Then all 3 should be switched to "off" and
at the end the original status should be restored.

The first tasks work fine, but the restoring is not working.
After running, all lights are off, even if e.g. NumLock was
activated before.
The boolean a is true, but still the NumLock will not be restored.
Whats wrong?

I am using Java 1.5, Netbeans 6.1, WinXP
and this is my code:




Thank you for your help and greetings from Munich.
Peter

[edit]Add code tags. CR[/edit]

[ July 30, 2008: Message edited by: Peter Klotz ]
[ July 30, 2008: Message edited by: Campbell Ritchie ]
 
Jules Bach
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
huh? that's odd..I just tried you code in eclipse...and found something similar...

I'm confused too now!
 
Bill Cruise
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried the same thing with the same results. What I did find is that if I change the state in the second set of setLockingKeyState instructions to false:



It sets all states back to what they were originally. It works the same for turning the lights on (you have to change both calls to setLockingKeyState to the same thing). I wonder if the Toolkit is buffering the original state for you?
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Depending on the platform, setting the state of a locking key may involve event processing and therefore may not be immediately observable through getLockingKeyState.
Is it possible it may be a timing problem ? Unsetting and then setting straight afterwards may confuse the event processor or the OS. Try putting a few seconds delay after setting them all to false.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50258
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A 2-second delay doesn't seem to make any difference. I tried printing out the states of the 3 lamps, and what they printed seemed the same before and after, even though the lights resolutely stayed off.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50258
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And welcome to JavaRanch
 
Campbell Ritchie
Sheriff
Pie
Posts: 50258
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Campbell Ritchie:
A 2-second delay doesn't seem to make any difference. I tried printing out the states of the 3 lamps, and what they printed seemed the same before and after, even though the lights resolutely stayed off.
That was on Windows.

On Fedora I got an UnsupportedOperationException.
 
Rob Spoor
Sheriff
Pie
Posts: 20669
65
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just tested this as well in both Java 1.4.2 and Java 6, and both have the same strange behaviour, even with a 15 second delay.

I have then tested toggling the num-lock state from a UI, with one toggle button. No problem whatsoever. Until I toggled it back from the same method that is, that one was no success.
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
works OK using the anti-state (is that a word?)

 
Juan Manuel Alberto de los Santos
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


hope it helps
[ July 31, 2008: Message edited by: Juan Manuel Alberto de los Santos ]
 
Peter Klotz
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello to all.
Thank you for your help.
Sadly nothing seems to solve the problem so far.

Well anyhow, this is just for some playing with code and no serious problem.
-> Juan and Michael: Your codes still do not reset the original state (e.g. only NumLock==On) after switching all off, at least not on my system.
-> Campbell Ritchie: Thanks for the welcome ;-)

I will go on with the experiment the next days and let you know if I find something.

BTW: What chances do you give a keyboard that was just flooded by a huge cup of coffee?
 
Ronald Schild
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I launch this with caps, scroll and num ON, they are all turned off when the code has executed.



Output:

NUM_LOCK: true CAPS_LOCK: true SCRL_LOCK true
NUM_LOCK: true CAPS_LOCK: true SCRL_LOCK true
NUM_LOCK: true CAPS_LOCK: true SCRL_LOCK true


When I launch the same code with caps, scroll and num OFF, all are turned off after the code has run and the output changes to:


NUM_LOCK: false CAPS_LOCK: false SCRL_LOCK false
NUM_LOCK: false CAPS_LOCK: false SCRL_LOCK false
NUM_LOCK: false CAPS_LOCK: false SCRL_LOCK false


So running this code several times just turns all on, next off, next on, etc. While the output gives false information regarding to the actual state.

If I run this code with num ON, caps, scroll OFF, the result is that num is turned OFF and caps, scroll ON. So the states are toggled. The output is:


NUM_LOCK: true CAPS_LOCK: false SCRL_LOCK false
NUM_LOCK: true CAPS_LOCK: false SCRL_LOCK false
NUM_LOCK: true CAPS_LOCK: false SCRL_LOCK false


It seems that the state printed is the state was originally on, regardless of the state set during the code. It also seems that with these two blocks, only one is effective, namely the one that switches the original state. Removing block 1 or block 2 results in expected behaviour of the keyboard, but not in the output (the read state is still only the original state).

A large cup of coffee on the keyboard warrants are really new shiny one with more buttons
 
Ronald Schild
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As stated in the API (getLockingKeyState):

Depending on the platform, setting the state of a locking key may involve event processing and therefore may not be immediately observable through getLockingKeyState.


So I let my thread sleep for 6 (and later 20) seconds in between, but this does not change the output.

After more testing, I found out you can keep toggling the states with the opposite value of what getLockingKeyState returns (it only ever returns the initial state).

Let's say:



Returns true, the following will toggle the key trice:



Don't mind the horrible sleep code, it's just for testing.
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> BTW: What chances do you give a keyboard that was just flooded by a huge cup of coffee?

aha! a java keyboard
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> Juan and Michael: Your codes still do not reset the original state
> (e.g. only NumLock==On) after switching all off, at least not on my system.

with a slight variation, seems to work OK at resetting to original state
java 1.6, winxp

 
Peter Klotz
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looks like I do not completely understand why,
but now it works (in some cases).

Have a look and try this at home:
This code will flash your 3 lock-lights on the keybord in an
(almost) Knightrider-style (you remember KITT?), provided the
lights are in following order: NumLock-CapsLock-ScrollLock

At the end the Locks will reset to the original status.

This works fine, when the condition in the for-loop is "i < foo", where foo has to be an even number. If foo is odd, the Locks will reset to the oposite of the original state. (WHY? I do not know)

Thanks again to all and have fun :-)


[ July 31, 2008: Message edited by: Peter Klotz ]
 
Juan Manuel Alberto de los Santos
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Klotz:
Hello to all.
Well anyhow, this is just for some playing with code and no serious problem.
-> Juan and Michael: Your codes still do not reset the original state (e.g. only NumLock==On) after switching all off, at least not on my system.


Did you really try my code ?

you can remplace //*** Put here whatever you want to do ***// with Thread.sleep(5000) just to see the trick
 
Peter Klotz
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Juan,
I tried your code, but maybe I was using an odd number in my iteration (see previous post), so I got the oposite state than the beginning state.
If I enter the for-loop and use an even number your code works fine!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic