[fpc-pascal] Re: KeyPressed

[Lowell C. Savage]

"Tomas Hajny" wrote, in part:

> > I'm running an old DOS (originally compiled with TP) Pascal program that
> > uses the CRT unit.  It has several places where it uses KeyPressed/ReadKey
> > to pause a screen until the user responds.  It uses the same combination
> > to
> > read user input.  However, it appears to be a random function which
> > determines whether (or when?) a key is detected.
> >
> > For instance, when the program begins, it sets up the screen, (clears,
> > displays a title at the top, and displays some initial messages, then uses
> > "KeyPressed/ReadKey" to clear the keyboard buffer. then displays a "Press
> > any key to continue:" prompt and waits for a successful "KeyPressed"
> > (using
> > "REPEAT UNTIL KeyPressed;" and then discards the return from the following
> > ReadKey.
> >
> > The trouble is that after that "Press any key to continue" prompt comes
> > up,
> > I may need to press anywhere from 1 to 10 keys to get the "KeyPressed"
> > routine to see it.  (I inserted logging statements between each line of
> > code.)
> >
> > Any ideas?  (Note, please don't dig too much into this on my behalf--I'm
> > hoping someone else has run into this issue and figured it out.  Now that
> > I
> > know how to do it, I'm almost done with another DLL which does my keyboard
> > IO using the standard C libraries.  In other words, I'm replacing all my
> > "KeyPressed" and "ReadKey" calls with "CheckKey" and "GetKey" calls
> > respectively which, in turn, respectively call the C standard library
> > <conio.h> functions "_kbhit" and "getch".  But if there is a simple fix to
> > the KeyPressed issue, then my IO.pp unit can simply have an implementation
> > that calls KeyPressed and ReadKey instead of using the DLL.)
>
>First of all (as a general comment), you omitted one rather important
>information in your e-mail, and that is the target you compile for (plus
>some notes about the FPC version and the exact operating system version
>might help when discussing "strange" problems too - not everybody can link
>this to your previous e-mails in different thread). Anyway, I assume you
>talk about the Win32 target as in the other mails.

Yes, my apologies.  Windows XP development and target systems.  Both with 
the latest SPs and patches.

FPC 2.0.0.

>  If this is the case,
>I'd guess that the problem might come from having two (incompatible)
>message handlers installed. This can e.g. happen when using unit Crt in
>parallel to e.g. unit Keyboard or Mouse with the current FPC version
>(known issues), or the second message handler might be directly in your
>"complex" program. If you don't need the Crt unit for anything else than
>KeyPressed and ReadKey functions, I'd suggest to use equivalent functions
>from unit Keyboard (PollKeyEvent and GetKeyEvent) and check whether this
>helps - the advantage of unit Keyboard to the C library is that it's
>multi-platform. If that doesn't help (which is certainly possible, of
>course - I don't know which units you use, so I'm just guessing here), it
>could be due to a conflict with message handler installed in the external
>C library you use (which I don't know either) and then using the C library
>functions might be your only choice.
>
>Hope this helps

Some, perhaps....I ran into this problem when I was still compiling the 
program as a pure Pascal program.  (I had the interfaces to other languages 
commented out.)

I'm using: CRT, IO, DOS, Video, Printer, Graph, and Drivers.  It's only one 
or two modules that need Video, Printer, Graph and Drivers (not necessarily 
the same ones).  But, of course when it all gets linked together, you only 
need one reference to cause trouble, right?

And I don't care about multi-platform, so the C library DLL looks kind of 
like the way to go.


Lowell C. Savage
savage at lanl.gov
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)