Maybe not a bug?

In the following code:

Graphics 640,480,0

a = WaitKey()
Print a
'FlushKeys()
b$ = GetChar()
Print b$
c$ = GetChar()
Print c$

..if you hit the 'a' key for example it prints:
65
97
0

Why are two codes being fed to the keyboard queue? If you un-comment FlushKeys() it prints
65
0
0

..so WaitKey(), it seems, is putting two values in instead of one. Strangely, if you hit 'space' instead of 'a' you get the expected
16
0
0

Is this a bug or do I not understand these commands correctly?

Russell

Waitkey() will call keyhit and return the code of the keyhit. At the same time the key is added to a queue for use by Getchar. When Getchar runs it checks this queues and finds the key even though it has been returned by waitkey.
If you use Waitchar, rather than waitkey, you'll see the correct results.

On a side note, the other thing to note is that WaitKey()/GetKey() return the key codes (as per all those constants), whereas WaitChar()/GetChar() will return the ASCII code of the key pressed.

@JazzieB: Yes, and that's good to know.

@tonyg: That is an odd series of events, eh? So WaitKey() is a wrapper function for KeyHit()? I thought KeyHit() just returned the number of times a particular key has been hit since the last call (and on the same key)?

Maybe an optional flag for these commands, CLEAR_QUEUE, would be useful to clear the cue afterward if we want. Of course, FlushKeys() can be used.

I wish the exact nature of these commands was spelled out more thoroughly in the manual! (It's in the pipeline, I know) ;)

Russell