This inquiry pertains to Perl's keyboard key reading capabilities.

A slowly expanding international volunteer group of researchers are creating 
freeware software for humanitarian efforts such as disaster mitigation 
projects.  The latest ActiveState version of Perl is being used along with 
the Gnuplot program for graphics.  The programs are being developed on 
regular PC type computers with Windows software.  But we want them to be 
able to run on a variety of computers and also be used for CGI applications. 
Those are two of the reasons for going with Perl.  The main problem we are 
having has to do with the fact that no one in the group is an experienced 
Perl programmer.  So we are having to look around for information such as 
the following:

Many computer languages have a regular keyboard input statement such as the 
Perl readline command.  They also usually have commands for reading 
individual key presses without the need to hit the Enter key.

The only reference I have been able to find to a keyboard key read statement 
involves the IsKeyPressed command in the Win32-GuiTest module.  And I was 
unable to determine how to use it for two different things that an Inkey or 
Getkey statement might do in Basic for example.

How are the Ctrl, Shift, and Alt keys read?

When a key is read using IsKeyPressed, how can the Windows keyboard buffer 
be cleared for that key press?  IsKeyPressed does not appear to do that. 
And the next time a readline statement is encountered the previous key 
presses are still there.

Are there other key press read commands available in any of the Perl 
modules?

In article <d8qdnR0PUOnflL_XnZ2dnUVZ_tGdnZ2d@earthlink.com>, E.D.G.
<edgrsprj@ix.netcom.com> wrote:

> This inquiry pertains to Perl's keyboard key reading capabilities.
> 
> A slowly expanding international volunteer group of researchers are creating 
> freeware software for humanitarian efforts such as disaster mitigation 
> projects.  The latest ActiveState version of Perl is being used along with 
> the Gnuplot program for graphics.  The programs are being developed on 
> regular PC type computers with Windows software.  But we want them to be 
> able to run on a variety of computers and also be used for CGI applications. 
> Those are two of the reasons for going with Perl.  The main problem we are 
> having has to do with the fact that no one in the group is an experienced 
> Perl programmer.  So we are having to look around for information such as 
> the following:
> 
> Many computer languages have a regular keyboard input statement such as the 
> Perl readline command.  They also usually have commands for reading 
> individual key presses without the need to hit the Enter key.

Perl was originally developed for Unix. In that operating system, all
input/output devices are considered part of the file system, and
reading from a keyboard uses the same I/O functions as reading from a
file, so there are no special keyboard input statements. There are
functions that are used only for "terminal" I/O (what keyboards are
normally attached to) to set how special characters are interpreted.

> The only reference I have been able to find to a keyboard key read statement 
> involves the IsKeyPressed command in the Win32-GuiTest module.  And I was 
> unable to determine how to use it for two different things that an Inkey or 
> Getkey statement might do in Basic for example.
> 
> How are the Ctrl, Shift, and Alt keys read?

Perl depends upon the underlying operating system to detect the ctrl,
shift, and alt keys and modify the character passed to the program
accordingly. Detecting the modifier keys is a low-level function, and
Perl is a high-level language.

> When a key is read using IsKeyPressed, how can the Windows keyboard buffer 
> be cleared for that key press?  IsKeyPressed does not appear to do that. 
> And the next time a readline statement is encountered the previous key 
> presses are still there.
> 
> Are there other key press read commands available in any of the Perl 
> modules?

Look at the FAQ "How can I read a single character from a file? From
the keyboard?"

perldoc -q single

-- 
Jim Gibson

Quoth Jim Gibson <jimsgibson@gmail.com>:
> In article <d8qdnR0PUOnflL_XnZ2dnUVZ_tGdnZ2d@earthlink.com>, E.D.G.
> <edgrsprj@ix.netcom.com> wrote:
> 
> > This inquiry pertains to Perl's keyboard key reading capabilities.
> > 
> > A slowly expanding international volunteer group of researchers are
> > creating freeware software for humanitarian efforts such as disaster
> > mitigation projects.  The latest ActiveState version of Perl is
> > being used along with the Gnuplot program for graphics.  The
> > programs are being developed on regular PC type computers with
> > Windows software.  But we want them to be able to run on a variety
> > of computers and also be used for CGI applications. 

I would suggest that you refrain from including this paragraph of
justification in all your posts. I rather doubt anyone here is
interested in what you are doing or why, simply in what your Perl
problem is.

Getting a good feel for what is information is likely to be relevant to
solving a problem, and what is not, is an important part of learning
to be a programmer.

> > Those are two of the reasons for going with Perl.  The main problem we are 
> > having has to do with the fact that no one in the group is an experienced 
> > Perl programmer.  So we are having to look around for information such as 
> > the following:
> > 
> > Many computer languages have a regular keyboard input statement such as the 
> > Perl readline command.  They also usually have commands for reading 
> > individual key presses without the need to hit the Enter key.
> 
> Perl was originally developed for Unix. In that operating system, all
> input/output devices are considered part of the file system, and
> reading from a keyboard uses the same I/O functions as reading from a
> file, so there are no special keyboard input statements. There are
> functions that are used only for "terminal" I/O (what keyboards are
> normally attached to) to set how special characters are interpreted.

True, but beside the point.

> > The only reference I have been able to find to a keyboard key read
> > statement involves the IsKeyPressed command in the Win32-GuiTest
> > module.

You clearly didn't look very hard. Did you really not find
Term::ReadKey?

> > And I was unable to determine how to use it for two
> > different things that an Inkey or Getkey statement might do in Basic
> > for example.

You will need to clarify what those functions do. The last version of
BASIC I used (BBC BASIC IV on the Master 128) had INKEY and INKEY$ but
no GETKEY :).

> > How are the Ctrl, Shift, and Alt keys read?
> 
> Perl depends upon the underlying operating system to detect the ctrl,
> shift, and alt keys and modify the character passed to the program
> accordingly. Detecting the modifier keys is a low-level function, and
> Perl is a high-level language.

Perl's 'level' is not the point. Part of the point of Perl is that you
can access the OS at any level you choose, without losing high-level
advantages like automatic memory management.

Detecting actual key presses is a very system-dependant matter. You (the
OP) have implied you are using Win32: is this a console-mode
application, or a GUI? If it's console-mode, you probably want
Win32::Console; if it's a GUI application, whichever GUI toolkit you are
using will provide functions to read the keyboard events.

If you don't need to detect actual key presses (that is, you don't need
individual 'control-down' and 'control-up' notifications) but simply
need to read input without waiting for a newline (what a Unix person
would call 'cbreak mode'), you want the Term::ReadKey module.

> > When a key is read using IsKeyPressed, how can the Windows keyboard buffer 
> > be cleared for that key press?  IsKeyPressed does not appear to do that. 
> > And the next time a readline statement is encountered the previous key 
> > presses are still there.
> > 
> > Are there other key press read commands available in any of the Perl 
> > modules?
> 
> Look at the FAQ "How can I read a single character from a file? From
> the keyboard?"
> 
> perldoc -q single

Meh. That FAQ answer is not terribly good. All that stuff about doing
termios by hand is neither appropriate nor portable nowadays.

Ben

"Tad J McClellan" <tadmc@seesig.invalid> wrote in message 
news:slrnh28jc9.jbr.tadmc@tadmc30.sbcglobal.net...

> The OP apparently could not be troubled to check the Perl FAQ
> before posting to the Perl newsgroup.

I did go through the Perl FAQ and tried everything I could find that I also 
understood.

For some reason I did not any information regarding the Term::ReadKey option 
but will try to find it now and see if I can get it to work.

"Jim Gibson" <jimsgibson@gmail.com> wrote in message 
news:010620091109383384%jimsgibson@gmail.com...

> Look at the FAQ "How can I read a single character from a file? From
> the keyboard?"

Thanks for the comments.

"Ben Morrow" <ben@morrow.me.uk> wrote in message 
news:rvkdf6-30k.ln1@osiris.mauzo.dyndns.org...

Thanks for the information.

> I would suggest that you refrain from including this paragraph of
> justification in all your posts. I rather doubt anyone here is
> interested in what you are doing or why, simply in what your Perl
> problem is.

There is (or has been in the past) a reason for including that information. 
I am advising researchers including government scientists around the world 
regarding a number of different humanitarian and/or disaster mitigation 
projects.  And based on my recommendations some will probably be using a 
Perl - Gnuplot graphics (to some extent) combination to do some of their 
research.  If I have a problem understanding the information then the rest 
of the researchers will have a problem.  So, some good programming advise 
can save multiple parties some time and effort.

> You will need to clarify what those functions do. The last version of
> BASIC I used (BBC BASIC IV on the Master 128) had INKEY and INKEY$ but
> no GETKEY :).

What we essentially want to do is simply determine that a key was pressed, 
tell what key it was, and then clear that key press out of the Windows 
keyboard buffer.  One of the problems with IsKeyPressed in the mode I am 
using it is the fact I have to check each key of interest with statements 
like:

if (Win32::GuiTest::IsKeyPressed("A")){$keyboard = 'A'};
if (Win32::GuiTest::IsKeyPressed("B")){$keyboard = 'B'};

Some versions of Basic and other languages just say:

$keyboard = Inkey  for example.  And the program does the rest.

> Detecting actual key presses is a very system-dependant matter. You (the
> OP) have implied you are using Win32: is this a console-mode
> application, or a GUI? If it's console-mode, you probably want
> Win32::Console; if it's a GUI application, whichever GUI toolkit you are
> using will provide functions to read the keyboard events.

Win32::GuiTest  is a package that I downloaded from one of the repository 
sites and installed in Perl.  It lets you read keys and also send keystrokes 
to Windows as if they were typed in by hand.

Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Jim Gibson <jimsgibson@gmail.com>:
>> In article <d8qdnR0PUOnflL_XnZ2dnUVZ_tGdnZ2d@earthlink.com>, E.D.G.
>> <edgrsprj@ix.netcom.com> wrote:
>> 
>> > This inquiry pertains to Perl's keyboard key reading capabilities.

>> > The only reference I have been able to find to a keyboard key read
>> > statement involves the IsKeyPressed command in the Win32-GuiTest
>> > module.
>
> You clearly didn't look very hard. Did you really not find
> Term::ReadKey?


The OP apparently could not be troubled to check the Perl FAQ
before posting to the Perl newsgroup.


>> > Are there other key press read commands available in any of the Perl 
>> > modules?
>> 
>> Look at the FAQ "How can I read a single character from a file? From
>> the keyboard?"
>> 
>> perldoc -q single
>
> Meh. That FAQ answer is not terribly good. All that stuff about doing
> termios by hand is neither appropriate nor portable nowadays.


Right.

But all 3 of the FAQs from

    perldoc -q keyboard

mention Term::ReadKey  :-)



-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Use Term::ReadKey;
ReadMode 4;
$key = ReadKey(-1);
ReadMode 0;

Variations of that code will read most of the keyboard keys and also clear 
the keyboard buffer.

However, that code does not appear to be able to read special keys such as 
Page Down, the F1 through F12 keys, and the arrow keys with Windows.

Does anyone know if there is some variation of the code that can identify 
those keys?  If not then IsKeyPressed can still be used to identify them. 
That will not be a problem.  Being unable to clear letter and number 
keyboard presses from the keyboard buffer with IsKeyPressed was a problem.

For some reason, Term::ReadKey does not appear to be in the documentation 
index for the Perl version that I have.  I had to do a search for it and 
then look at the different pages that the search identified.

Just for general interest,

One of the projects that I am working on involves making recommendations to 
science researchers regarding a good programming language for relatively 
simple projects.  That could be especially important for science students 
around the world who do not have unlimited amounts of time to learn a 
complex computer language or hundreds of dollars to purchase one.

Another researcher and I evaluated a number of programming languages 
including Fortran and Basic programs.  And when the evaluation process was 
finished I made the decision that the ActiveState version of Perl was 
probably our best choice.  Quite a few evaluation criteria were involved.

So far, we have not looked into Perl's graphics capabilities.  But I know 
that it can be used quite effectively with the Gnuplot graphics program. 
And both will apparently run on different types of computers with various 
operating systems.

The main problem that the people that I am working with have had with Perl 
is with the documentation.  In my opinion it assumes that you have a certain 
level of programming experience to start with.  Just determining how to 
download the program and start using the ppm feature to load various modules 
is difficult if there is no one around to explain what steps need to be 
taken.  I don't know if the latest Perl download lets people create exe 
versions of the program.  But I do know that it took me about two years of 
trying different things before I was finally able to determine what modules 
had to be linked with the program and what type of commands to give the 
computer in order to create them.  Once you know how to do all of that they 
are easy to create.

It is my opinion that if you can get past those types of problems, Perl is a 
powerful, versatile, and easy programming language to work with.  And future 
efforts might involve attempting to get a "science" module developed that 
would contain all of the features that science researchers need such as trig 
functions, automatic pipe creation routines, graphics, exe program 
generation code, and most important of all, more easily understood 
documentation.  Science researchers generally need to use only a limited 
number of commands.  And if they are explained in simple terms then with 
very little effort people can start creating programs.

I would imagine that the ActiveState people would like to sell more of their 
specialty software such as the program development kits.  And if more 
science researchers and others are using Perl then I would expect that they 
should be able to do that.

Quoth "E.D.G." <edgrsprj@ix.netcom.com>:
> Use Term::ReadKey;
> ReadMode 4;
> $key = ReadKey(-1);
> ReadMode 0;
> 
> Variations of that code will read most of the keyboard keys and also clear 
> the keyboard buffer.
> 
> However, that code does not appear to be able to read special keys such as 
> Page Down, the F1 through F12 keys, and the arrow keys with Windows.

As I said before, you can do this with Win32::Console.

> Does anyone know if there is some variation of the code that can identify 
> those keys?  If not then IsKeyPressed can still be used to identify them. 
> That will not be a problem.  Being unable to clear letter and number 
> keyboard presses from the keyboard buffer with IsKeyPressed was a problem.

Win32::GuiTest is *not* a good module to use here. It's far too
low-level for general-purpose input: for one thing, it reads keys that
are destined for other applications, which is hardly a reasonable thing
to do.

> For some reason, Term::ReadKey does not appear to be in the documentation 
> index for the Perl version that I have.  I had to do a search for it and 
> then look at the different pages that the search identified.

WHat 'documentation index'? Perl doesn't normally have one. Do you mean
the ActiveState-provided HTML documentation? I believe you can
regenerate the TOC using the ActivePerl::DocTools module, but I don't
have an AS Perl to hand.

Ben

On 2009-06-02, E.D.G. <edgrsprj@ix.netcom.com> wrote:
>
> And future 
> efforts might involve attempting to get a "science" module developed that 
> would contain all of the features that science researchers need such as trig 
> functions, automatic pipe creation routines, graphics, exe program 
> generation code, and most important of all, more easily understood 
> documentation.

The science researchers I have worked with have easily understood most
of the Perl documentation.  And these people are not necessarily skilled
programmers.

> Science researchers generally need to use only a limited 
> number of commands.

Which ones?  Biology researchers have a huge range of needs.  I can't
imagine that other fields are much different.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On 2009-06-02, E.D.G. <edgrsprj@ix.netcom.com> wrote:
> Use Term::ReadKey;
> ReadMode 4;
> $key = ReadKey(-1);
> ReadMode 0;
>
> Variations of that code will read most of the keyboard keys and also clear 
> the keyboard buffer.
>
> However, that code does not appear to be able to read special keys such as 
> Page Down, the F1 through F12 keys, and the arrow keys with Windows.

A correctly compiled Term::ReadKey should be able to get any key.
However, AFAIK, there is no working Windows port of Perl yet; so I
would not be surprised if Term::ReadKey is not supported under Windows
as well.

(I never tried to compile with RSX-NT; if this would work, then
Term::ReadKey would read special keys under Win as well...)

Hope this helps,
Ilya

On Mon, 1 Jun 2009 20:26:38 -0500, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

>Just for general interest,
>
>One of the projects that I am working on involves making recommendations to 
>science researchers regarding a good programming language for relatively 
>simple projects.  That could be especially important for science students 
>around the world who do not have unlimited amounts of time to learn a 
>complex computer language or hundreds of dollars to purchase one.
>
>Another researcher and I evaluated a number of programming languages 
>including Fortran and Basic programs.  And when the evaluation process was 
>finished I made the decision that the ActiveState version of Perl was 
>probably our best choice.  Quite a few evaluation criteria were involved.
>
>So far, we have not looked into Perl's graphics capabilities.  But I know 
>that it can be used quite effectively with the Gnuplot graphics program. 
>And both will apparently run on different types of computers with various 
>operating systems.
>
>The main problem that the people that I am working with have had with Perl 
>is with the documentation.  In my opinion it assumes that you have a certain 
>level of programming experience to start with.  Just determining how to 
>download the program and start using the ppm feature to load various modules 
>is difficult if there is no one around to explain what steps need to be 
>taken.

That is your responsibility. You wrote your app with all the bells and whistles
with intent to have it used by people who never did Perl.
Write an msi script and install the whole shebang for them.

>  I don't know if the latest Perl download lets people create exe 
>versions of the program.  But I do know that it took me about two years of 
>trying different things before I was finally able to determine what modules 
>had to be linked with the program and what type of commands to give the 
>computer in order to create them.  Once you know how to do all of that they 
>are easy to create.
>
>It is my opinion that if you can get past those types of problems, Perl is a 
>powerful, versatile, and easy programming language to work with.  And future 
>efforts might involve attempting to get a "science" module developed that 
>would contain all of the features that science researchers need such as trig 
>functions, automatic pipe creation routines, graphics, exe program 
>generation code, and most important of all, more easily understood 
>documentation.  Science researchers generally need to use only a limited 
>number of commands.  And if they are explained in simple terms then with 
>very little effort people can start creating programs.

There is no intersection between these worlds other than specialist's.
You may have to send out paid programmers with your software.

>
>I would imagine that the ActiveState people would like to sell more of their 
>specialty software such as the program development kits.  And if more 
>science researchers and others are using Perl then I would expect that they 
>should be able to do that.

Perl is not for the faint hearted. More and more are NOT gravitatiting to it!
The more you learn about Perl, the less friendly it actually becomes.
The scientific analogy is that the Perl modules are the stars, galaxies and 
planets. Knowing what to do with it is Dark Matter/Energy.


-sln

"Ben Morrow" <ben@morrow.me.uk> wrote in message 
news:ddfef6-l7n.ln1@osiris.mauzo.dyndns.org...

> As I said before, you can do this with Win32::Console.

There is a part of the Perl code that I am not familiar with.  And probably 
as a result of that I could not get the Win32::Console module commands to 
work.  There appears to be an important part of the following experimental 
code that is missing.  And it is probably needed to get the Console commands 
to work.  I do know what the relationship is between @event and $event[1], 
$event[2], etc.


use Win32::Console;

repeat:;
@event = $CONSOLE->Input();
print @event, "\n";
sleep 1;
goto repeat;

"Ilya Zakharevich" <nospam-abuse@ilyaz.org> wrote in message 
news:slrnh29d0v.qfl.nospam-abuse@chorin.math.berkeley.edu...

> A correctly compiled Term::ReadKey should be able to get any key.
> However, AFAIK, there is no working Windows port of Perl yet; so I
> would not be surprised if Term::ReadKey is not supported under Windows
> as well.

Thanks for the comments.

With Windows and the ActiveState version of Perl I am guessing that the 
Win32::ReadKey commands don't return enough information to identify keys 
such as Page Down or the F1 to F12 and arrow keys.

The Win32::Console commands look like they should return all of the 
necessary information.  But so far I have not been able to get the commands 
to work.  It is probably just a simple coding problem.

If necessary I will be using a combination of ReadKey and IsKeyPressed 
commands.  The results are not perfect.  But they should get the effort past 
a keyboard buffer clearing problem I have been having.

"Keith Keller" <kkeller-usenet@wombat.san-francisco.ca.us> wrote in message 
news:fsjef6x593.ln2@goaway.wombat.san-francisco.ca.us...

> The science researchers I have worked with have easily understood most
> of the Perl documentation.  And these people are not necessarily skilled
> programmers.

I am working with researchers in countries around the world including a 
retired professional computer programmer.  Not one of those people knows 
anything about Perl.  And this is a major problem.  It has been my personal 
experience that when you are working with a computer language you need to 
have at least one expert who can explain things.  Right now if we run into 
even a minor problem it can stop forward progress on some project.  All of 
these people are doing this as volunteer work.  And so far there have not 
been any funds available to hire a programmer.  However, there is at least 
one foundation involved.  And I have been trying to convince the people 
there that they need to get some professional help for a particular CGI 
program development effort.  Progress is a little slow because most of the 
people speak English as a second language.

"Ben Morrow" <ben@morrow.me.uk> wrote in message 
news:ddfef6-l7n.ln1@osiris.mauzo.dyndns.org...

> WHat 'documentation index'? Perl doesn't normally have one. Do you mean
> the ActiveState-provided HTML documentation? I believe you can

Yes.  I have been using the ActiveState HTML documentation.  One of the 
pages lists all of the different modules etc.

<sln@netherlands.com> wrote in message 
news:vb4b25pd08a65j1lm7snijn8bo71g713fp@4ax.com...

> Perl is not for the faint hearted. More and more are NOT gravitatiting to 
> it!
> The more you learn about Perl, the less friendly it actually becomes.
> The scientific analogy is that the Perl modules are the stars, galaxies 
> and
> planets. Knowing what to do with it is Dark Matter/Energy.

Many of the scientists that I am working with don't know anything about 
programming in general.  That means that they don't know what is possible 
and what is not possible with any computer programs.  As I can do 
intermediate level programming work as well as work in different areas of 
science people are relying on me to tie everything together and provide some 
guidance for the efforts.

If you can get past the lack of necessary documentation for beginner and 
intermediate level programmers such as myself, I can assure you that Perl 
can be an exceptionally good language for scientists to use.  The reason 
entire groups of science researchers are not using it is probably because of 
those documentation problems.  You can see how much trouble I am having just 
trying to duplicate the following command that is standard with most of the 
languages I have worked with over the years:

$key = Inkey

It would read one character from the keyboard buffer and then clear that key 
press from the buffer.  I am surprised that the standard Perl version does 
not have an equivalent command as part of its regular code.

$dataline = readline STDIN;  works fine, but not for individual key presses.

Most of the people that I am working with would likely be using Perl with 
the Windows operating system.  Some have a Perl compiler on their system. 
They can work with the source code.  Other just run the exe programs I am 
generating.

It is my guess that one of the reasons I am having problems getting 
information regarding Perl code is that many of the people posting to this 
Newsgroup are using it with UNIX or Linux and not Windows.

On Wed, 3 Jun 2009 01:37:19 -0500, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

><sln@netherlands.com> wrote in message 
>news:vb4b25pd08a65j1lm7snijn8bo71g713fp@4ax.com...
>
>> Perl is not for the faint hearted. More and more are NOT gravitatiting to 
>> it!
>> The more you learn about Perl, the less friendly it actually becomes.
>> The scientific analogy is that the Perl modules are the stars, galaxies 
>> and
>> planets. Knowing what to do with it is Dark Matter/Energy.
>
>Many of the scientists that I am working with don't know anything about 
>programming in general.  That means that they don't know what is possible 
>and what is not possible with any computer programs.  As I can do 
>intermediate level programming work as well as work in different areas of 
>science people are relying on me to tie everything together and provide some 
>guidance for the efforts.
>
>If you can get past the lack of necessary documentation for beginner and 
>intermediate level programmers such as myself, I can assure you that Perl 
>can be an exceptionally good language for scientists to use.  The reason 
>entire groups of science researchers are not using it is probably because of 
>those documentation problems.  You can see how much trouble I am having just 
>trying to duplicate the following command that is standard with most of the 
>languages I have worked with over the years:
>
>$key = Inkey
>
>It would read one character from the keyboard buffer and then clear that key 
>press from the buffer.  I am surprised that the standard Perl version does 
>not have an equivalent command as part of its regular code.
>
>$dataline = readline STDIN;  works fine, but not for individual key presses.
>
>Most of the people that I am working with would likely be using Perl with 
>the Windows operating system.  Some have a Perl compiler on their system. 
>They can work with the source code.  Other just run the exe programs I am 
>generating.
>
>It is my guess that one of the reasons I am having problems getting 
>information regarding Perl code is that many of the people posting to this 
>Newsgroup are using it with UNIX or Linux and not Windows.

I think that you are replying to everyone, regardless of what they have to say.
To me, you represent an attention troll.

Everytime a key is pressed on a Dos machine (aka Windows), it generates an
interrupt. If you don't know what "interrupts" or "handlers" are, then you
wouldn't know what to do with it, even if you could.

The subject matter, as simple as it is, is ten miles over your head.

What are the ramifications if the "arrow" key is held down?

Give me a break. If you want to actually PAY me to do your work, then so
be it. You are spending an awfull lot of time and energy on something that
is FREE AS A BIRD scientific, or are you just a troll.

-sln

On Wed, 3 Jun 2009 01:09:43 -0500, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

>"Keith Keller" <kkeller-usenet@wombat.san-francisco.ca.us> wrote in message 
>news:fsjef6x593.ln2@goaway.wombat.san-francisco.ca.us...
>
>> The science researchers I have worked with have easily understood most
>> of the Perl documentation.  And these people are not necessarily skilled
>> programmers.
>
>I am working with researchers in countries around the world including a 
>retired professional computer programmer.  Not one of those people knows 
>anything about Perl.  And this is a major problem.  It has been my personal 
>experience that when you are working with a computer language you need to 
>have at least one expert who can explain things.  Right now if we run into 
>even a minor problem it can stop forward progress on some project.  All of 
>these people are doing this as volunteer work.  And so far there have not 
>been any funds available to hire a programmer.  However, there is at least 
>one foundation involved.  And I have been trying to convince the people 
>there that they need to get some professional help for a particular CGI 
>program development effort.  Progress is a little slow because most of the 
>people speak English as a second language.

Hey, give it a rest. You are constantly on this board, whatever the subject
you start, hiding behind some sort of guilded crest of research.

Total HOGWASH !!

-sln

<sln@netherlands.com> wrote in message 
news:1t9c25tsrnss4ia7m6mgn8g68qdt42tuh5@4ax.com...

This is what we are doing.  It is a "learn as you go" type of effort.

Government agencies and disaster mitigation and scientific groups need 
certain types of computer programs to process various types of data. 
However, for certain project they don't know how to get the science part to 
work.  What I myself am doing is largely generating demonstration computer 
programs that show them what needs to be done.  Then they can have their own 
programmers convert those demonstration programs into ones their agencies or 
scientific groups will use.  If necessary they can hire programmers to do 
the work.

A while ago I developed an Excel spreadsheet program that produces certain 
types of charts.  And a programmer I am working with is presently trying to 
write a Perl - Gnuplot program that generates the same charts.  The idea is 
that it would be more interactive than the Excel program.  Unfortunately, he 
has never used Perl.  And the two of us have our hands full trying to 
determine how to get different Perl commands to work.

"Ben Morrow" <ben@morrow.me.uk> wrote in message 
news:ddfef6-l7n.ln1@osiris.mauzo.dyndns.org...

The ReadKey commands are now in use in my programs.

What I discovered is that when a Perl screen is the visible one, the ReadKey 
commands work fine for detecting key presses.  However when a Gnuplot 
graphics screen is the one being displayed, the IsKeyPressed command has to 
be used.  ReadKey doesn't see any key presses for some reason.  That 
probably has to do with the way that Windows works.

>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:

    EDG> Many of the scientists that I am working with don't know
    EDG> anything about programming in general.  That means that they
    EDG> don't know what is possible and what is not possible with any
    EDG> computer programs.

None of the scientists I have ever known were born knowing how to use an
electron microscope or a gas chromatograph, or how to solve differential
equations or diagram organic chemicals.  If the tool is useful to their
research, they can learn to use it.

Perl is far simpler to use than an oscilloscope, and has the advantage
of being freely available for anyone who has a computer.

    EDG> If you can get past the lack of necessary documentation for
    EDG> beginner and intermediate level programmers such as myself,

_Elements of Programming with Perl_
_Learning Perl_
_Beginning Perl_
_Programming Perl_
_Perl Best Practices_
_Higher-Order Perl_ 

What more do you need?  What problems do you have with these books?  If
you just go on about "the lack of necessary documentation" -- well,
there's a couple thousand pages of good, useful documentation in those
six books, and together they cover all the necessary parts of using
Perl.  If you aren't using them, use them, and your problem is solved;
if you are using them, and find them inadequate, explain what you find
inadequate about them instead of just complaining in the vaguest of
terms about "the lack of necessary documentation."

The problem you have consistently, that I've noticed more than once in
your postings here, is that you cannot isolate the problem you are
having, and in particular you cannot separate relevant information from
irrelevant information.  As a classic example, you come here with a
problem about wanting to read key input immediately on Windows, and you
preface your actual question with a dissertation about the people who
are working on the project and how vitally important it is.  Not only is
this completely irrelevant to the problem you're trying to solve, it's
also likely to make the people who would otherwise help you skip over
the post because you can't get to the point in the first paragraph.

Further, you make it almost impossible to constructively help you.
http://catb.org/esr/faqs/smart-questions.html -- "How to Ask Questions
the Smart Way" -- is a document you should read over and over again and
internalize.  In particular, the sections entitled "Be precise and
informative about your problem" and "Be explicit about your problem."

A perfect example of you asking poor questions: you asked about how to
read a key from the keyboard.  In the process of someone answering the
question, it turned out that you had not read the FAQ questions on the
matter, and that you actually knew about Win32::ReadKey but failed to
mention that in your question.  Reading the FAQ would have helped you
write a better question, if nothing else, and asking a specific question
about Win32::ReadKey would have helped you get a useful answer.
Instead, people are forced to play 20 Questions with you, and that gets
old fast.

    EDG> The reason entire groups of science researchers are not using
    EDG> it is probably because of those documentation problems.  

What documentation problems?  Be specific.

(And someone who doesn't read the FAQ before asking a question really
doesn't have much standing to criticize the documentation he doesn't
use.)

    EDG> It is my guess that one of the reasons I am having problems
    EDG> getting information regarding Perl code is that many of the
    EDG> people posting to this Newsgroup are using it with UNIX or
    EDG> Linux and not Windows.

No.  The reasons you are having problems getting information is because
you do not seem able or willing to do your own research and to ask your
questions in a way that they are easy to answer.  The second or third
time someone needs to play 20 Questions with you, investing a couple of
hours responding to you *just to find out what the problem really is*,
he or she decides that it's not worth that much effort to help someone
who apparently doesn't want to be helped enough to frame the question
intelligently.

Charlton


-- 
Charlton Wilbur
cwilbur@chromatico.net

[please quote a sensible amount of the article you are replying to]
[please wrap your articles at 72 characters to allow for quoting]

Quoth "E.D.G." <edgrsprj@ix.netcom.com>:
> "Ben Morrow" <ben@morrow.me.uk> wrote in message 
> news:ddfef6-l7n.ln1@osiris.mauzo.dyndns.org...
> 
> The ReadKey commands are now in use in my programs.
> 
> What I discovered is that when a Perl screen is the visible one, the
> ReadKey commands work fine for detecting key presses.  However when a
> Gnuplot graphics screen is the one being displayed, the IsKeyPressed
> command has to be used.  ReadKey doesn't see any key presses for some
> reason.  That probably has to do with the way that Windows works.

Let me ask you this: do you really want your Perl program to respond to
keys pressed when some random window, say a Word window, has the focus?
If you use IsKeyPressed that is exactly what you will get.

You really need to start writing this program in a more structured way.
Instead of displying a gnuplot window, get gnuplot to write the graph to
a file. Then create a window using one of the many GUI toolkits on CPAN
(perldoc -q gui) which displays the graph and responds to keypresses in
the appropriate manner.

This is not going to be a terribly easy program to write. GUI
programming is inherently difficult, and for all that toolkits like Tk
try to make things simple, there is a certain amount of difficulty that
cannot be removed.

Ben

Charlton Wilbur <cwilbur@chromatico.net> wrote in 
news:86zlcpz8mt.fsf@mithril.chromatico.net:

>>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:

>     EDG> If you can get past the lack of necessary documentation for
>     EDG> beginner and intermediate level programmers such as myself,
> 
> The problem you have consistently, that I've noticed more than once in
> your postings here, is that you cannot isolate the problem you are
> having, and in particular you cannot separate relevant information from
> irrelevant information.

He has been doing that for years. 

Sinan

-- 
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

On Jun 3, 10:09=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> [please quote a sensible amount of the article you are replying to]
> [please wrap your articles at 72 characters to allow for quoting]
>
> Quoth "E.D.G." <edgrs...@ix.netcom.com>:
>
> > "Ben Morrow" <b...@morrow.me.uk> wrote in message
> >news:ddfef6-l7n.ln1@osiris.mauzo.dyndns.org...
>
> > The ReadKey commands are now in use in my programs.
>
> > What I discovered is that when a Perl screen is the visible one, the
> > ReadKey commands work fine for detecting key presses. =A0However when a
> > Gnuplot graphics screen is the one being displayed, the IsKeyPressed
> > command has to be used. =A0ReadKey doesn't see any key presses for some
> > reason. =A0That probably has to do with the way that Windows works.
>
> Let me ask you this: do you really want your Perl program to respond to
> keys pressed when some random window, say a Word window, has the focus?
> If you use IsKeyPressed that is exactly what you will get.
>
> You really need to start writing this program in a more structured way.
> Instead of displying a gnuplot window, get gnuplot to write the graph to
> a file. Then create a window using one of the many GUI toolkits on CPAN
> (perldoc -q gui) which displays the graph and responds to keypresses in
> the appropriate manner.
>
> This is not going to be a terribly easy program to write. GUI
> programming is inherently difficult, and for all that toolkits like Tk
> try to make things simple, there is a certain amount of difficulty that
> cannot be removed.
>
> Ben

Let me see if I can help clarify things.

The program is currently written in TrueBasic and has been rewritten
in FreeBasic and now Perl.

None of these languages are totally satisfactory. The intent is to
display a scrollable series of graphs which are controlled by a
keypress. Right arrow moves one day to the right, Ctrl-right arrow
move a year to the right for example.

TrueBasic handles this easily because it gives the keycode for any key
pressed and that can be used in a CASE statement to control what
happens. Perl doesn't seem to like interactive input, perhaps because
it was originally intended as a text processor working with files.

Roger

>>>>> "r" == rogerh906  <rogerh906@gmail.com> writes:

    r> TrueBasic handles this easily because it gives the keycode for
    r> any key pressed and that can be used in a CASE statement to
    r> control what happens. Perl doesn't seem to like interactive
    r> input, perhaps because it was originally intended as a text
    r> processor working with files.

Perl is just fine with interactive input.  The difference here is that
you're spawning a gnuplot process to display the input, and when the
user presses a key, the notification of that key goes to gnuplot and not
to the Perl process.  Perl is not so fine at intercepting keypresses
that are sent to other processes.

It sounds to me like the project needs at least one person who actually
understands how to program, and who understands how event-driven GUIs
and interprocess communication work.  Without that, you're going to keep
switching from language to language, and blaming each language in turn
because you don't understand the architectural issues and because it's
the architecture, not the language, that's causing the problem.

Charlton



-- 
Charlton Wilbur 
cwilbur@chromatico.net

On 2009-06-03, Ben Morrow <ben@morrow.me.uk> wrote:
>> What I discovered is that when a Perl screen is the visible one, the
>> ReadKey commands work fine for detecting key presses.  However when a
>> Gnuplot graphics screen is the one being displayed, the IsKeyPressed
>> command has to be used.  ReadKey doesn't see any key presses for some
>> reason.  That probably has to do with the way that Windows works.
>
> Let me ask you this: do you really want your Perl program to respond to
> keys pressed when some random window, say a Word window, has the focus?

Obviously, either you have not used gnuplot, or know its
implementation.  ;-)

[gnuplot has an IPC channel, so that keys pressed in the preview
window are passed to the caller.  But the caller must participate in IPC...]

Ilya

On Jun 3, 2:07=A0pm, Charlton Wilbur <cwil...@chromatico.net> wrote:
> >>>>> "r" =3D=3D rogerh906 =A0<rogerh...@gmail.com> writes:

>
> Perl is just fine with interactive input. =A0The difference here is that
> you're spawning a gnuplot process to display the input, and when the
> user presses a key, the notification of that key goes to gnuplot and not
> to the Perl process. =A0Perl is not so fine at intercepting keypresses
> that are sent to other processes.
>
> It sounds to me like the project needs at least one person who actually
> understands how to program, and who understands how event-driven GUIs
> and interprocess communication work. =A0Without that, you're going to kee=
p
> switching from language to language, and blaming each language in turn
> because you don't understand the architectural issues and because it's
> the architecture, not the language, that's causing the problem.
>
> Charlton
>
Sorry Charleton, you think wrong. I've been programming for a LONG
time, starting with Fortran IV, then PL/I and finally TrueBasic. And
this isn't an interprocess problem anyway, as I can't get any of the
sample code to work in Perl either. It was my intention to do the
whole thing in Perl, once I discovered the graphics modules.

Roger

>>>>> "r" == rogerh906  <rogerh906@gmail.com> writes:

(quoting me)

    >> It sounds to me like the project needs at least one person who
    >> actually understands how to program, and who understands how
    >> event-driven GUIs and interprocess communication work.  Without
    >> that, you're going to keep switching from language to language,
    >> and blaming each language in turn because you don't understand
    >> the architectural issues and because it's the architecture, not
    >> the language, that's causing the problem.
    >> 
    >> Charlton

    r> Sorry Charleton, you think wrong. 

It's Charlton, actually.  No E.  And it was two lines above where you
typed that, and you failed to copy it correctly.  This does not bode
well for your attention to detail, which is a hard requirement for being
a successful programmer.

    r> I've been programming for a LONG time, starting with Fortran IV,
    r> then PL/I and finally TrueBasic. 

Great!  So the project has someone who knows programming on it.

Does it have anyone who understands event-driven GUI programming or
interprocess communication?

    r> And this isn't an interprocess problem anyway, as I can't get any
    r> of the sample code to work in Perl either. 

.....er, maybe it *doesn't* have someone who understands programming on
it.  Back to Square 1!

Charlton





-- 
Charlton Wilbur
cwilbur@chromatico.net

> It's Charlton, actually. =A0No E. =A0And it was two lines above where you
> typed that, and you failed to copy it correctly. =A0This does not bode
> well for your attention to detail, which is a hard requirement for being
> a successful programmer.
>
> =A0 =A0 r> I've been programming for a LONG time, starting with Fortran I=
V,
> =A0 =A0 r> then PL/I and finally TrueBasic.
>
> Great! =A0So the project has someone who knows programming on it.
>
> Does it have anyone who understands event-driven GUI programming or
> interprocess communication?
>
> =A0 =A0 r> And this isn't an interprocess problem anyway, as I can't get =
any
> =A0 =A0 r> of the sample code to work in Perl either.
>
> ....er, maybe it *doesn't* have someone who understands programming on
> it. =A0Back to Square 1!
>

 Charlton, is this a "help the newcomer" blog or a "be a smart aleck
site"?

I can play it either way but the former is more useful.

I repeat, the problem is to get some way to identify which key was
pressed so the program can take appropriate action. I've tried a
number of perl routines which are supposed to do that and while they
compile without error they do not print anything.

Roger

Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2009-06-03, Ben Morrow <ben@morrow.me.uk> wrote:
> >> What I discovered is that when a Perl screen is the visible one, the
> >> ReadKey commands work fine for detecting key presses.  However when a
> >> Gnuplot graphics screen is the one being displayed, the IsKeyPressed
> >> command has to be used.  ReadKey doesn't see any key presses for some
> >> reason.  That probably has to do with the way that Windows works.
> >
> > Let me ask you this: do you really want your Perl program to respond to
> > keys pressed when some random window, say a Word window, has the focus?
> 
> Obviously, either you have not used gnuplot, or know its
> implementation.  ;-)

No, and no.

> [gnuplot has an IPC channel, so that keys pressed in the preview
> window are passed to the caller.  But the caller must participate in IPC...]

That would be a good solution then, though I'm beginning to doubt the OP
will be able to see it :(.

Ben

Quoth rogerh906@gmail.com:
>  Charlton, is this a "help the newcomer" blog or a "be a smart aleck
> site"?

It's neither. It's a Usenet group for discussing Perl. If in the course
of the discussion things are mentioned which are useful to newcomers,
then great. There is, however, no reason to expect they will be.

Ben

>>>>> "r" == rogerh906  <rogerh906@gmail.com> writes:

    >> ....er, maybe it *doesn't* have someone who understands
    >> programming on it.  Back to Square 1!


    r> Charlton, is this a "help the newcomer" blog or a "be a smart
    r> aleck site"?

It's neither a blog nor a website.  It's a newsgroup.

You say you have 20 years of experience with computers?  Indeed.

Charlton


-- 
Charlton Wilbur
cwilbur@chromatico.net

"Ben Morrow" <ben@morrow.me.uk> wrote in message 
news:spjif6-ir2.ln1@osiris.mauzo.dyndns.org...

> Let me ask you this: do you really want your Perl program to respond to
> keys pressed when some random window, say a Word window, has the focus?
> If you use IsKeyPressed that is exactly what you will get.

I thought that this discussion was going along reasonably well.  It looks 
like something happened in the last day to change the tone.

Let me say again, regardless of what limitations it might have, I personally 
like the Perl programming language better than any other I have worked with 
over the years.  And I am recommending that other researchers use it. 
Whatever documentation is needed for the people that I work with can be 
easily created and stored on a Web page.

Those comments regarding documentation were just added information.  The 
question that needed an answer is how to get Perl to detect key presses.

The main Perl program that needs to do that has already been up and running 
for some time.  And since early March of 2009 it has been available for use 
by governments and researchers around the world as a freeware download.

It opens a pipe to Gnuplot and tells the program to display certain types of 
charts.  The IsKeyPressed command is used to detect key presses when Gnuplot 
charts are being displayed.  So, the answer to that one question is "Yes." 
The Perl program needs to be able to detect key presses when some other 
program is the one actively displaying data.  Another of these programs has 
Perl detect key presses when a Word for Windows program is the one being 
displayed.

Two problems were encountered with IsKeyPressed.

First, as far as I can tell, it does not do a good job of removing the key 
press from the Windows keyboard buffer.  So if a readline command is later 
used to get a line from the buffer the last character is still there.

The second problem is that it would read only a limited number of keys.  For 
example, it does not appear to be able to distinguish between upper and 
lower case key presses.

The ReadKey commands are somewhat more versatile.  But when Gnuplot is the 
screen being displayed they don't detect key presses from what I can tell

The Win32::Console commands look even better.  But I could not get them to 
work at all.

So the Perl - Gnuplot program that is already running has now been upgraded 
so that it uses both the IsKeyPressed commands for when Gnuplot is 
displayed, and the ReadKey and readline commands for when Perl is the active 
screen.  Between them they take care of the key detection and buffer clear 
problems.  If I can eventually determine how to get the Win32::Console 
commands to work I will probably use them instead of ReadKey.

Finally, now that the ReadKey commands are being used, Perl and Gnuplot are 
actually doing about all of the things that we need them to do.  And from 
this point discussions will probably focus on the proper format for using 
various commands such as "open" etc.

"Charlton Wilbur" <cwilbur@chromatico.net> wrote in message 
news:86vdndytbd.fsf@mithril.chromatico.net...

> It sounds to me like the project needs at least one person who actually
> understands how to program, and who understands how event-driven GUIs
> and interprocess communication work.  Without that, you're going to keep

Increasingly complex Perl programs are being gradually developed.  And there 
are simply some code usage and program data sharing and control matters that 
need to be addressed as the efforts progress.  Things are now actually 
working fairly well.  Perl has to be used in part because it will eventually 
probably be necessary to develop some moderately complex CGI programs.

>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:

    EDG> Let me say again, regardless of what limitations it might have,
    EDG> I personally like the Perl programming language better than any
    EDG> other I have worked with over the years.  And I am recommending
    EDG> that other researchers use it. Whatever documentation is needed
    EDG> for the people that I work with can be easily created and
    EDG> stored on a Web page.

This is irrelevant to your question.

    EDG> Those comments regarding documentation were just added
    EDG> information.  The question that needed an answer is how to get
    EDG> Perl to detect key presses.

This is also irrelevant to your question.

    EDG> The main Perl program that needs to do that has already been up
    EDG> and running for some time.  And since early March of 2009 it
    EDG> has been available for use by governments and researchers
    EDG> around the world as a freeware download.

Still more content that's irrelevant to your question.

    EDG> It opens a pipe to Gnuplot and tells the program to display
    EDG> certain types of charts.  The IsKeyPressed command is used to
    EDG> detect key presses when Gnuplot charts are being displayed.
    EDG> So, the answer to that one question is "Yes." The Perl program
    EDG> needs to be able to detect key presses when some other program
    EDG> is the one actively displaying data.  Another of these programs
    EDG> has Perl detect key presses when a Word for Windows program is
    EDG> the one being displayed.

Finally, useful information!

(Most people would have moved on to the next article long before this point.)

    EDG> Two problems were encountered with IsKeyPressed.

    EDG> First, as far as I can tell, it does not do a good job of
    EDG> removing the key press from the Windows keyboard buffer.  So if
    EDG> a readline command is later used to get a line from the buffer
    EDG> the last character is still there.

    EDG> The second problem is that it would read only a limited number
    EDG> of keys.  For example, it does not appear to be able to
    EDG> distinguish between upper and lower case key presses.

    EDG> The ReadKey commands are somewhat more versatile.  But when
    EDG> Gnuplot is the screen being displayed they don't detect key
    EDG> presses from what I can tell

You are misunderstanding the purpose of IsKeyPressed.  

Windows has the notion of a stream of events.  Each event belongs to a
particular process.  At some point, and I'm not a Windows programmer so
I don't know where precisely this happens, this is translated into a
character of input for programs that think in terms of stdin/stdout.

Now, Windows routes each event to the window that it pertains to.
Keyboard events go to the active window.  When you're running Gnuplot,
this is the Gnuplot window, not the Perl window.  This is the core of
your problem, and why I think you need someone who understands
event-driven GUI programming to get involved.

The workaround you've chosen bypasses the event loop and deals directly
with events.  This means that you get told when a key is pressed -- but
you have to deal with it on the level of translating Shift plus A into
capital-A yourself.  This is almost certainly not what you really want
to do, and if you had that aforementioned event-driven GUI programmer on
staff, that's what he or she would tell you too.

Charlton



-- 
Charlton Wilbur
cwilbur@chromatico.net

"Charlton Wilbur" <cwilbur@chromatico.net> wrote in message 
news:86fxefzuhf.fsf@mithril.chromatico.net...

> This is irrelevant to your question.

Thanks for the comments.  Once again, the programming philosophy is somewhat 
different for the questions I am asking than for probably most of the 
questions other people are asking.

To a large extent, the programs I am developing are designed to simply show 
various organizations that a certain type of application will work and what 
it can accomplish.  If they like the application then they can have their 
own programmers duplicate and expand it using Perl if they like, or whatever 
other language they prefer.  I expect that in most cases it would be one of 
the C family languages.

So, these demonstration programs don't need perfect code.  All they need to 
do is show that something can be done.  And the IsKeyPressed command was not 
producing the needed result for all of the applications I have been 
developing.

As I have been saying, Perl combined with Gnuplot is an excellent language 
pairing for doing this type of work.  And the combination of IsKeyPressed, 
ReadKey, and readline will apparently get the job done for these 
demonstration programs.  Also with my other Perl Newsgroup information 
requests, for the most part, all I need is something that will work. 
Experienced programmers can fill in the blanks if governments etc. like an 
application.

Another approach to the key press question with Windows is to have the Perl 
program start some independently running Windows program that would read the 
key presses and dump the results into a file that the Perl program and other 
programs could check say 10 times a second to see if some key has been 
pressed.  That would take care of the entire matter.  And I am planning to 
explore that approach with some Windows experts.

On 2009-06-05, E.D.G. <edgrsprj@ix.netcom.com> wrote:
>
> Thanks for the comments.  Once again, the programming philosophy is somewhat 
> different for the questions I am asking than for probably most of the 
> questions other people are asking.

That seems impossibly unlikely.

> To a large extent, the programs I am developing are designed to simply show 
> various organizations that a certain type of application will work and what 
> it can accomplish.  If they like the application then they can have their 
> own programmers duplicate and expand it using Perl if they like, or whatever 
> other language they prefer.

Thank you for making my point so quickly.

--keith


-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On Thu, 4 Jun 2009 21:00:14 -0500, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

[snip]

>Another approach to the key press question with Windows is to have the Perl 
>program start some independently running Windows program that would read the 
>key presses and dump the results into a file that the Perl program and other 
>programs could check say 10 times a second to see if some key has been 
>pressed.  That would take care of the entire matter.  And I am planning to 
>explore that approach with some Windows experts.

You know of course about layered device drivers. Some keyboard companies
insert thier own driver in the chain, or even bypass the chain, enableing
them to do hot keys and so forth. This is a simple matter to do.

It all has to do with the interrupt mask. The driver sets the mask, inserts
itself in the device chain, catches the interrupt then reads the port.

The driver can be installed by calling CreateFile() with the driver name,
returning a handle by which you can communicate immediate with DeviceIoControl(),
immediate (if needed), then queue up asynchronous read requests with ReadFile()
using OverlappedIO.
That user mode process that starts the device, can be an intermediary to
another processes, your Perl program.

This will not cause any detriment to the normal windows message loops as your 
inserted device will just be an observer. That is, unless you want it to skip
passing along certain IRP's to the rest in the chain (with that affinity),
which of course you can control from the user mode monitor app, to do or not,
with discression. Of course, the other app's will not like this (should you
choose to be an active paricipant of change).

But, then your back to square 1, your user mode app will have to communicate
with a running perl app via a pipe.

Seems kind of silly huh?

Btw, if I inserted a file system overlay driver (filter), was protecting my file from
being seen by user mode win32, you would have no way of seeing it or removeing it
without being able to boot up without my driver being installed. Now days they call
that a rootkit. Once a kernel mode driver is installed, it lives in a veritable
play ground of OS lovelynes, able to do anything it wants.

I'm really glad we had this opportunity to talk.


-sln

<sln@netherlands.com> wrote in message 
news:drvg251dpl0kisi5hmjag43so1cnudotg7@4ax.com...

What is presently being considered is having a Visual Basic program for 
example watch for key presses.  If it saw one it might store information 
such as the words "Right Arrow" in a file called c:\keypress.txt.  It might 
also clear the keyboard buffer at the same time.  Perl, Basic, Fortran or 
even Gnuplot programs that were running at the time would check the contents 
of the keypress.txt file perhaps ten times a second and act on whatever key 
press information they found in the file.  The key checking program would be 
started with a system command linked if necessary with a Windows shortcut. 
And it might be sent an End command through some other text file that it 
checked itself. File sharing like that does not appear to be a problem if 
certain precautions are taken. One reason for doing this is to have Gnuplot 
draw a plot and then have different things display on the plot when various 
keys are pressed. Having Perl send Gnuplot commands and data through a pipe 
appears to be fast enough for my own applications.

On Thu, 4 Jun 2009 23:58:57 -0500, "E.D.G." <edgrsprj@ix.netcom.com> wrote:

><sln@netherlands.com> wrote in message 
>news:drvg251dpl0kisi5hmjag43so1cnudotg7@4ax.com...
>
>What is presently being considered is having a Visual Basic program for 
>example watch for key presses.  If it saw one it might store information 
>such as the words "Right Arrow" in a file called c:\keypress.txt.  It might 
>also clear the keyboard buffer at the same time.

We are talking about Windows. Windows, at its lower level core, is a collection of,
using the Dos analogy, multiple, single process machines.

There is a reason the term 'focus' was pattented by Mshit. The FOCUS is a
very big deal on the Wondows OS, very big!! You don't understand that, thats why
I snipped all your other stuff.

I guess you could get in touch with primitavies that do DeviceIoControl but probably
not unless you have the FOCUS. Its a circular, spiraling argument, leading to a
black hole, event horizon as far as the OS is concerned.

Unless the process EXCLUSIVELY owns the standard device/device chain, there is no construct
the OS will allow that will, accros the board, clear the 'keyboard buffer'.
This is not Dos 2.0, and VB is way down on the food chain.

-sln

>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:

    EDG> "Charlton Wilbur" <cwilbur@chromatico.net> wrote in message
    EDG> news:86fxefzuhf.fsf@mithril.chromatico.net...

    >> This is irrelevant to your question.

    EDG> Thanks for the comments.  Once again, the programming
    EDG> philosophy is somewhat different for the questions I am asking
    EDG> than for probably most of the questions other people are
    EDG> asking.

Your programming philosophy is completely irrelevant to every question
you've yet asked.  And by the time you've finished explaining your
programming philosophy, the mission statement for your project, and the
reasons everyone should help you, most sane people have skipped ahead to
the next article.

Did you read "How to Ask Questions the Smart Way"?
http://catb.org/esr/faqs/smart-questions.html

If you preface your question with three screens full of information that
is *completely irrelevant* to the problem you're having and the question
you're asking, people will skip over it. 

    EDG> To a large extent, the programs I am developing are designed to
    EDG> simply show various organizations that a certain type of
    EDG> application will work and what it can accomplish.  If they like
    EDG> the application then they can have their own programmers
    EDG> duplicate and expand it using Perl if they like, or whatever
    EDG> other language they prefer.  I expect that in most cases it
    EDG> would be one of the C family languages.

If this becomes an issue, you can say "This is a prototype and doesn't
have to have perfect code." Of course, experienced software developers
will find that amusing, because many of us have worked on "prototype"
systems that are older than we are.

Charlton



-- 
Charlton Wilbur
cwilbur@chromatico.net

On Wed, 03 Jun 2009 10:36:58 -0400, Charlton Wilbur wrote:

>>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
> 
>     EDG> Many of the scientists that I am working with don't know EDG>
>     anything about programming in general.  That means that they EDG>
>     don't know what is possible and what is not possible with any EDG>
>     computer programs.
> 
> None of the scientists I have ever known were born knowing how to use an
> electron microscope or a gas chromatograph, or how to solve differential
> equations or diagram organic chemicals.  If the tool is useful to their
> research, they can learn to use it.

The amount of learning involved is very big, and not every scientist is 
good at computer programming.

> Perl is far simpler to use than an oscilloscope, and has the advantage
> of being freely available for anyone who has a computer.

Sorry but Perl is a lot more complicated than an average oscilloscope.

>     EDG> If you can get past the lack of necessary documentation for
>     EDG> beginner and intermediate level programmers such as myself,
> 
> _Elements of Programming with Perl_
> _Learning Perl_
> _Beginning Perl_
> _Programming Perl_
> _Perl Best Practices_
> _Higher-Order Perl_
> 
> What more do you need?  What problems do you have with these books? 

I have a problem with "Programming Perl" - actually I hate it.

> If
> you just go on about "the lack of necessary documentation" -- well,
> there's a couple thousand pages of good, useful documentation in those
> six books

Most scientists are already busy with other things.

>, and together they cover all the necessary parts of using
> Perl.  If you aren't using them, use them, and your problem is solved;
> if you are using them, and find them inadequate, explain what you find
> inadequate about them instead of just complaining in the vaguest of
> terms about "the lack of necessary documentation."

It sounds like you are giving orders.

> The problem you have consistently, that I've noticed more than once in
> your postings here, is that you cannot isolate the problem you are
> having, and in particular you cannot separate relevant information from
> irrelevant information.  As a classic example, you come here with a
> problem about wanting to read key input immediately on Windows, and you
> preface your actual question with a dissertation about the people who
> are working on the project and how vitally important it is.  Not only is
> this completely irrelevant to the problem you're trying to solve, it's
> also likely to make the people who would otherwise help you skip over
> the post because you can't get to the point in the first paragraph.

But he did get an answer.

> Further, you make it almost impossible to constructively help you.
> http://catb.org/esr/faqs/smart-questions.html -- "How to Ask Questions
> the Smart Way" -- is a document you should read over and over again and
> internalize.  In particular, the sections entitled "Be precise and
> informative about your problem" and "Be explicit about your problem."

Sorry but I'll never be able to take anything written by Eric Raymond 
seriously after reading his blog. In fact whatever he says I'd be tempted 
to suggest doing the opposite.

> A perfect example of you asking poor questions: you asked about how to
> read a key from the keyboard.  In the process of someone answering the
> question, it turned out that you had not read the FAQ questions on the
> matter, and that you actually knew about Win32::ReadKey but failed to
> mention that in your question.  Reading the FAQ would have helped you
> write a better question, if nothing else, and asking a specific question
> about Win32::ReadKey would have helped you get a useful answer. Instead,
> people are forced to play 20 Questions with you, and that gets old fast.

But you have kept on writing quite a bit now, so perhaps you are enjoying 
this interaction with E.D.G. more than you care to admit.

>     EDG> The reason entire groups of science researchers are not using
>     EDG> it is probably because of those documentation problems.
> 
> What documentation problems?  Be specific.

"perldoc perlre".

"perldoc CGI".

The perlre documentation actually got worse going from Perl 5.8 to 5.10. 
Sad but true. A bit like the Apache documentation, which got worse going 
from 1.3 to 2.2. Who was it who raised the suspicions about people trying 
to sell books by deliberately writing bad documentation?
 
> (And someone who doesn't read the FAQ before asking a question really
> doesn't have much standing to criticize the documentation he doesn't
> use.)
> 
>     EDG> It is my guess that one of the reasons I am having problems
>     EDG> getting information regarding Perl code is that many of the
>     EDG> people posting to this Newsgroup are using it with UNIX or EDG>
>     Linux and not Windows.
> 
> No.  The reasons you are having problems getting information is because
> you do not seem able or willing to do your own research and to ask your
> questions in a way that they are easy to answer.  The second or third
> time someone needs to play 20 Questions with you, investing a couple of
> hours responding to you *just to find out what the problem really is*,
> he or she decides that it's not worth that much effort to help someone
> who apparently doesn't want to be helped enough to frame the question
> intelligently.

But it is worth the effort to write 200 or so lines complaining about the 
whole thing? That doesn't add up.