question on capturing keys

hi

i read that Term::ReadKey can capture keys typed on the keyboard.so if
i code a perl script to capture keys typed using Term::ReadKey and run
the perl script as background process in Windows
environment(Win32::process maybe?), will it still capture any keys
typed?
thanks..

In article <c0837966.0409271841.381f9805@posting.google.com>,
justme <eight02645999@yahoo.com> wrote:
:i read that Term::ReadKey can capture keys typed on the keyboard.so if
:i code a perl script to capture keys typed using Term::ReadKey and run
:the perl script as background process in Windows
:environment(Win32::process maybe?), will it still capture any keys
:typed?

No, Term::ReadKey only reads keystrokes on the device or file
whose filehandle it operates on. On Unix systems, that is usually
either STDIN or /dev/tty . In either case, it's the input stream to
a single process, not to the overall system.

Unix is inherently a multiuser operating system, and does not have
the concept of "the keyboard" as such -- at the Term::ReadKey level,
it just knows about byte streams, which could be coming from any
of a number of different sources. One of those sources might happen
to be the only keyboard physically attached to the computer, but
unix does not make that distinction at the Term::ReadKey level,
and is equally happy dealing with keystrokes coming via the network
from machines halfway around the world.

The Term::Readkey module is more or less intended to be a portable
emulation of the way Unix handles bytestreams that might come from
keyboards [but might not.]


Historically, there was much more of an assumption in Windows
that there was *a* keyboard, and that it is physically attached
to the computer, and that the one and only user is typing on it.
Modern versions of Windows have cleaned all that up internally,
but still give ways to hook into keystrokes from "the" keyboard.

It isn't that Windows can do something that Unix cannot -- it's
more that Unix has a clear notion that there can be multiple
displays and multiple keyboards, and it divorces that from the level
that the majority of "Unix" operates at. In Unix, if you wanted
to "capture keys in the background", then the way to do it would
be to put a transparent window "on top" of the other windows for
a particular "display", and arrange to have that transparent
window receive all the <key> notifications... and to pass those
notifications on to the next window down after doing whatever it
needs to do. But that's operated on an event+callback structure,
not by using anything like the Term::ReadKey level. Keystrokes
that make it through the X event loop get turned into characters
that are sent to the character device driver that is the level
that Term::ReadKey interacts with.

I do not know what the method would be in MS Windows to read all the
keystrokes. It would depend in part on which version of Windows,
with noticable differences between the NT and non-NT versions.
("Windows XP" is an NT version, but Windows 98 was non-NT.)


When you are investigating these methods, you need to ask yourself
what is it -exactly- that you want to record. If, for example, the
user presses the left SHIFT key and releases it again, do you want
to record that press and that release? If the user is holding down
the left SHIFT key and presses the 'a' key, then do you want to receive
"<capital-A> pressed, <capital-A> released" notifications, or do you want
"<left-shift> pressed, <a> pressed, <a> released, <left-shift> released" ?
Do you need to differentiate between left-shift and right-shift? Do you
need to record only those keystrokes that occur within a particular window,
or do you need to record *all* keystrokes -- for example, do you need
to record that the user has just gone up to the window frame and gone
through the menus to "Save", or do you want to ignore that and just
record typing? Or just record mouse-positioning and button presses
within the window (e.g., for a "paint" program) ? What about when the
user is using non-English keyboards or non-English text: do you need
the "o" stroke seperate from the "umlaut" stroke to go over it, or
do you want just the "o-umlaut" character?
--
Admit it -- you ped ahead to find out how this message ends!