INKEY oddity?
cgp
seeing in years past (I may be mistaken).
The following snippet of code has a REPEAT loop which intercepts key
presses as shown.
REPEAT
x1=y-SGN(x)*SQR(ABS(b*x-c))
IF INKEY(-102) THEN PROCmap : REM "M" key saves screen
IF INKEY(-30) THEN PROCfinish : REM F12 saves everything
Do stuff
UNTIL FALSE
; etc
The "M" key saves the screen to a predetermined filename.
PROCfinish includes the request to save a datafile under a user input
filename via:
INPUT"Filename to save variables",v$
v%=OPENOUT(v$)
However, the INPUT request prints the INPUT text to the screen
followed by the letter "m"
i.e. the input filename is prepended with the INKEY character.
Clearly this latter is remaining in the keyboard buffer. Of course I
can clear it with OS_Byte 15.
What I wish to know is this behaviour correct, or should the buffer
have been flushed by the INPUT statement or otherwise?
George Pearce
Richard Russell
> What I wish to know is this behaviour correct, or should the buffer
> have been flushed by the INPUT statement or otherwise?
INPUT doesn't flush the keyboard buffer (at least, not on the versions
of BBC BASIC I've just checked: BASIC 4 on a BBC Master, Brandy and
BBC BASIC for Windows).
> Of course I can clear it with OS_Byte 15.
To ensure platform independence I'd prefer to use REPEAT UNTIL INKEY(0)
=-1
Richard.
http://www.rtrussell.co.uk/
Steve Fryatt
<e4e32ec1-ba44-4a4c...@f16g2000yqm.googlegroups.com>:
> The following snippet of code has a REPEAT loop which intercepts key
> presses as shown.
>
> REPEAT
> x1=y-SGN(x)*SQR(ABS(b*x-c))
>
> IF INKEY(-102) THEN PROCmap : REM "M" key saves screen
> IF INKEY(-30) THEN PROCfinish : REM F12 saves everything
>
> Do stuff
>
> UNTIL FALSE ; etc
>
> The "M" key saves the screen to a predetermined filename.
Negative INKEY doesn't clear the input buffer: it just reports on whether
the key in question is held down at themoment when it is called. Is there a
reson for doing it this way, and not using INKEY(0)?
> PROCfinish includes the request to save a datafile under a user input
> filename via:
> INPUT"Filename to save variables",v$
> v%=OPENOUT(v$)
>
> However, the INPUT request prints the INPUT text to the screen
> followed by the letter "m"
> i.e. the input filename is prepended with the INKEY character.
> Clearly this latter is remaining in the keyboard buffer. Of course I
> can clear it with OS_Byte 15.
>
> What I wish to know is this behaviour correct, or should the buffer
> have been flushed by the INPUT statement or otherwise?
This has been the behaviour of Negative INKEY since the days of the BBC
Micro.
--
Steve Fryatt - Leeds, England
cgp
>
> > The following snippet of code has a REPEAT loop which intercepts key
> > presses as shown.
>
> > REPEAT
> > x1=y-SGN(x)*SQR(ABS(b*x-c))
>
> > IF INKEY(-102) THEN PROCmap : REM "M" key saves screen
> > IF INKEY(-30) THEN PROCfinish : REM F12 saves everything
>
> > Do stuff
>
> > UNTIL FALSE ; etc
>
> > The "M" key saves the screen to a predetermined filename.
>
> Negative INKEY doesn't clear the input buffer: it just reports on whether
> the key in question is held down at themoment when it is called. Is there a
> reson for doing it this way, and not using INKEY(0)?
>
I've never used INKEY(0) , and don't really understand the benefit. It
presumably now stores the ASCII code of the key pressed ( which rules
out my F12), rather than a negative INKEY value, but presumably still
leaves something in the buffer.
I would appreciate some illumination here.
cheers
George Pearce
Simon Willcocks
cgp <pear...@freeuk.com> wrote:
> I've never used INKEY(0) , and don't really understand the benefit. It
> presumably now stores the ASCII code of the key pressed ( which rules
> out my F12), rather than a negative INKEY value, but presumably still
> leaves something in the buffer.
>
> I would appreciate some illumination here.
>HELP INKEY
INKEY 0 to 32767: function waits <number> centiseconds to read character.
INKEY -255 to -1: function checks specific key for TRUE|FALSE.
INKEY -256: function gives operating system number.
INKEY(0) will return the ASCII code of the first keypress in the buffer, or
-1 if the buffer is empty. Since you know from the -ve INKEY that a key has
been pressed, you know there's a character in the buffer; use INKEY(0) to
remove it.
Try this for fun:
REPEAT:P. INKEY(100):U. FALSE
f12 won't put anything in the buffer, so you can choose to either not call
INKEY, or just ignore the returned -1. (The former is probably better.)
Simon
--
ROLF - The RISC OS Look and Feel on Linux.
http://stoppers.drobe.co.uk
http://ro-lookandfeel.blogspot.com/
druck
> I've never used INKEY(0) , and don't really understand the benefit. It
> presumably now stores the ASCII code of the key pressed ( which rules
> out my F12), rather than a negative INKEY value, but presumably still
> leaves something in the buffer.
Negative INKEYs are for realtime detection of key presses and releases,
such as required in games. Character values aren't removed from the
buffer as it's expected they will be discarded.
Positive INKEYs wait 0 or more centi-seconds for a character to be
entered, and removes it from the buffer. It will return straight away if
a character is already in the buffer.
---druck
Steve Fryatt
> On Dec 12, 12:08 pm, Steve Fryatt <n...@stevefryatt.org.uk> wrote:
>
> > Negative INKEY doesn't clear the input buffer: it just reports on
> > whether the key in question is held down at themoment when it is called.
> > Is there a reson for doing it this way, and not using INKEY(0)?
>
> I've never used INKEY(0) , and don't really understand the benefit.
The benefit is that it clears the keypress from the input buffer, which is
more useful when trying to interwork with the INPUT statement.
> It presumably now stores the ASCII code of the key pressed ( which rules
> out my F12), rather than a negative INKEY value, but presumably still
> leaves something in the buffer.
INKEY(+ve) and GET (along with their $ counterparts) take single characters
from the buffer, remvoing them but leaving the following characters in situ.
GET stops and waits for a keypress; INKEY(0) polls the buffer and continues
returning -1 if no keypresses are waiting. If you're waiting for the user
to do something, then use GET; if you need to do stuff in the background,
use INKEY(0).
Assuming you're running outside the Wimp, and only on RISC OS, then you
probably want to investigate the use of *FX 221-228 to get the function keys
to return numeric codes instead of typing macros into the buffer.
If you do
SYS "OS_Byte",225,200,0
SYS "OS_Byte",221,220,0
in your initialisation, then INKEY(0) would return 221 if F1 was pressed,
through to 229 for F9. F10, F11 and F12 would return 230, 231 and 232
respectively. See the PRMs or StrongHelp for more info: these calls also
make things like Print return codes that you can read, and there are other
OS_Byte calls to set Shift- and Ctrl- modifier values too.
Before your program exits (including from an error handler) you should do
SYS "OS_Byte",225,1,0
SYS "OS_Byte",221,1,0
to return the keys to their default actions (the Wimp will reset them
anyway, when you return to the Desktop, but it's good practice).
Richard Russell
> Negative INKEYs are for realtime detection of key presses and releases,
> entered, and removes it from the buffer.
It's perhaps worth adding that if you use negative INKEY it's possible
that the keypress won't be detected at all (if it was pressed for less
than the time between INKEYs) or you may detect the same keypress two
or more times (if it was pressed for more than the time between
INKEYs). If you use positive INKEY you're guaranteed to receive
exactly one character for each keypress, however short or long it was
(unless held down long enough to 'repeat').
Richard.
http://www.rtrussell.co.uk/
cgp
Thanks for all these replies chaps
Now much clearer - have learned a lot.
The info in the BASIC manual is pretty scant. For instance I have not
seen INKEY(0) documented as described.
Is it somewhere in the PRMs
George Pearce