Re: question on capturing keys

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 09/28/04


Date: 28 Sep 2004 03:29:28 GMT

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 peeked ahead to find out how this message ends!


Relevant Pages

  • Re: Opera pain
    ... emacs, vi, are all about keys. ... tab menu instead. ... With Opera, i have to read the titles or small thumbnails. ... in my key macro app (on Windows it's AutoHotkey http://xahlee.org/mswin/autohotkey.html ...
    (comp.infosystems.www.authoring.html)
  • Re: My experiences with a Dell D620 Laptop. Part 1.
    ... Specification of the Dell. ... highlights extra key functions on the keys accessible via the Fn key. ... Powerbook and MacBook screens. ... - There are the usual irritating Intel Core Duo and 'Windows Designed ...
    (comp.sys.mac.advocacy)
  • RE: The string universal unique identifier (UUID) is invalid.
    ... when you install multiple brands of cards in Windows XP. ... The issue may be caused by a corrupt winsock or TCP/IP ... Delete corrupted registry keys and reinstall TCP/IP protocol. ...
    (microsoft.public.windowsxp.network_web)
  • Re: My experiences with a Dell D620 Laptop. Part 1.
    ... This post is to show Mac Users just what they are missing compared to a 9 month old PowerBook G4/15.4/1.6Mhz and a white MacBook. ... On a number of occasions I've opened up the machine only to find the battery is drained or find a very hot laptop in my bag. ... It has a rather tacky looking two-tone appearance around the keyboard and trackpad with the keys being a different colour to the inner silver 'ring'. ... Why couldn't these go underneath with the WIndows XP license label? ...
    (comp.sys.mac.advocacy)
  • Re: Domain Local group and Require strong. GPO Problem
    ... Microsoft MVP (Windows Server System: ... >> controller that is not capable of encrypting secure channel traffic with ... >> that all such domain controllers must be running Windows 2000 or later ... >> Session keys used to establish secure channel communications between ...
    (microsoft.public.win2000.security)