Mail Archives: djgpp/1999/02/17/02:48:14
On Mon, 15 Feb 1999, John Scott Kjellman wrote:
> If you run it and then press a few keys, it will display the character (if
> printable) and the getxkey() value for each key. The '1' key should be
> translated to a '2' and the '0' key should be dropped, but isn't!
The problem is real. The wrapper overwrites the FLAGS with their
original value, before it does an IRET. I know how to fix this (a simple
change to the wrapper is all it takes), but I want first to be sure I
don't introduce bugs with that change. The wrappers were written by
several very clever and experienced people, and they might have done this
for a good reason (e.g., some bits in FLAGS are very dangerous). I asked
the rest of DJGPP developers whether they are aware of any problems.
In the meantime, you can work around this problem by changing the scan
code to 0; this will also make the key be ignored (as no key has a zero
scan code).
Btw, I think your code has to check for key-break events, not only for
key-make events. Who knows what will some BIOSes do if you only
substitute the make scan codes?
> BTW, in my
> previous posting I stated 0x30 was the scan code for the '0' key, it is not 0x0B
> is, 0x30 is the ASCII value ;-) This just doesn't seem to follow the docs....
Where does the docs contradict this? ASCII keys return their ASCII codes
in getxkey, not their scan codes.
- Raw text -