Read keys without keyboard focus

[Canonical Latin]

I have an non-gui application that is running in the background. I want
to be able stop this when I press <ESC> key (or any other key). The
only way I can think of is to get to the OS queue for the keyboard! Is
there any other way? Can Java do this? I already know that java can
access "private" OS resources in java.awt.Robot. But a robout cannot
read the keyboard...

 

[Thomas Weidenfeller]

I have an non-gui application that is running in the background. I want
to be able stop this when I press <ESC> key (or any other key). The
only way I can think of is to get to the OS queue for the keyboard! Is
there any other way?

Forget about the key-reading junk. A process which runs in the
background is not meant to communicate with a console and is usually not
attached to one.

Send a SIGTERM to the JVM, assuming the VM was *not* started with the
-Xrs options
(http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html#Xrs). If
it was, then you need a SIGKILL. But that doesn't give the JVM and your
application any chance of an orderly shutdown.

/Thomas

 

[Canonical Latin]

Of course most programs are not attached to a consol and they talk to
the keyboard just fine. Whether my non-gui application should or should
not receive inputs from keyboard is none-of-...Oh well, let's be
nice,...lets just say that in my case it really makes sense to have no
windows and still listen to the keyboard.

Since my problem came up, I have done some reading about signals. They
are useless because they are so antiquated. Signals probably made sense
in a UNIX like environment 20 years ago when the idea of socket and
thread was not within the reach of a typical C program. Here is the
solution that I came up with that solved my problem. Unfortunately, it
is not a pure java solution. Although, it could be made into one, if
SUN introduced an OS specific class (java.awt.KeyboardInterceptor,
perhaps?) similar to other peered classes.

My idea is very simple. Write an OS specific program that sends a copy
of all keys pressed to a (host/port) -- non-blocking write (If SUN
volunteers, this would be the part that they write for all supported
OS's.) In your java program (or any other program) have a thread that
listens to that (port) and communicates with other threads. Done!

Conceivably, the KeyboardInterceptor class (the native program) could
be made more elaborate by sending certain key sequences to certain
host/port. So in this scenario, you would register a set of key
bindings to a host/port with KeyboardInterceptor and then you don't
have to listen to all keys...beats the hell outta signals--which ar OS
specific anyway. Nay?

 

[Thomas Weidenfeller]

have to listen to all keys...beats the hell outta signals--which ar OS
specific anyway. Nay?

Are you asking me? Since you just told me to shut up I guess you have to
find someone else to discuss your bright ideas.

/Thomas

 

[Canonical Latin]

A: I have a problem...
B: Your problem has no solution since it's not in the FAQ.
A: But it does! Here is an idea...
B: Don't talk back to me...
A: (somewhat surprised)...Well, of course!

 

[Antti S. Brax]

A: I have a problem...
B: Your problem has no solution since it's not in the FAQ.
A: But it does! Here is an idea...
B: Don't talk back to me...
A: (somewhat surprised)...Well, of course!

Keep talking. Somebody might still think that you are a smart
person.

 

[Canonical Latin]

Lol, this is really funny. And to whom would I be shownig off in an
anonymous post? Keep trolling buddy, better luck next time!

 

[iksrazal]

Trying to get past the flames for a moment - I'm just finishing up on
an NIO war - the non-standard but somewhat available C function kbhit()
does what you seemingly describe, but the JDK itself has no similair
functionality. This issue was filed as a bug report 8 years ago to sun
and is worth a read for the comments and work arounds.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4050435

Don't give up Signals so easily, here's an article that shows a nice
chart between the OS's and how to use signals in Java.

http://www-106.ibm.com/developerworks/ibm/library/i-signalhandling/

HTH,
iksrazal
http://www.braziloutsource.com/

 

[Canonical Latin]

Yeah, a kbhit() would solve the problem and it is a better idea than
what I had described because it is simpler. In fact, what I had
described can be build from kbhit().

I had read the IBM article before and that was my main reason to think
of signals as "outdated". If I'm not mistaken, the article describes
in great detail that they are not only OS dependent, but also JVM
dependent!

Thanks for the bug report reference; I was not aware of it. But of
course, this is a fundamental problem and I'm not surprised that it
has so many votes. In fact, I'm putting my vote for this update too.
As many have noted this is only a few lines of JNI that should really
be provided by SUN.

I feel that this problem does not deserve as much time as I've put
into it. I mean, I prefer to be working on my application rather than
"patching up" holes in java--just a question of productivity, IMHO.

 

[Canonical Latin]

I'm not actively pursuing this problem anymore. But thinking about it
a bit more, neither kbhit() function nor the bug report referenced
before is really much related to this problem (although it is nice to
have them in Java). Signals are really not relevant either. In all
those cases, the issue is related to when you do have the keyboard
focus. When you don't have the keyboard focus and still want to read
the keys, then you really need to intercept the OS. At least in the
windoz family of OS's this is not too difficult with a "hook" to the
keyboard...