Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!purdue!haven!decuac!shlump.nac.dec.com!sousa.enet.dec.com!pinbot.enet.dec.com!ervin
From: ervin@pinbot.enet.dec.com (Joseph James Ervin)
Newsgroups: comp.sys.handhelds
Subject: Re: (HP48SX)  Strange behavior...bug?
Message-ID: <991@sousa.enet.dec.com>
Date: 22 Mar 91 14:32:48 GMT
References: <990@sousa.enet.dec.com>
Sender: newsa@sousa.enet.dec.com
Reply-To: ervin@pinbot.enet.dec.com (Joseph James Ervin)
Organization: Digital Equipment Corporation
Lines: 41

In article <990@sousa.enet.dec.com>, I wrote:

|> Next, I tried this simple variation;  I wanted to wait for 10 key
|> presses and then exit.
|> 
|> \<< 1 10 FOR I DO UNTIL KEY END NEXT \>>
|> 
|> This program should wait for 10 key presses, and leave the 10 keycodes
|> on the stack.  Unfortunately, the actual number of key presses I must
|> make tends to vary from 10 to as high as 14.  I realize that the KEY
|> function does not wait for a key press, but I see the same behavior even
|> when I press the keys very slowly (once a second) an very deliberately
|> (firmly holding the key down each time I press one).
|> 
|> I am very surprised that this simple program would behave so
|> |>unpredictably.  

Another thing I noticed is that if I add a couple instructions to the
outer loop to slow it down a bit, it seems to work more reliably.  I get
the feeling like the there may be a problem with the KEY instruction
when it is called repeatedly very quickly.  It seems to work fine for
the first key press, but it sometimes misses key presses (even slow
deliberate ones) which occur after a previous key press.  The following
code seems to work more reliably:

\<< 1 10 FOR I DO UNTIL KEY END 1200 .05 BEEP NEXT \>>

This program causes the calculator to emit a very short beep after every
key press.  It _seems_ like the added delay between the time a key press
is detected to the next time that KEY is executed, causes the program to
work more reliably.

Since the KEY function does not wait for the key to be released before
continuing with the RPL stream, it must (apparently) make some attempt
to watch for "no key pressed", so that KEY will not interpret a single
key press as many key presses when used in a tight loop, such as in the
above code.

Has anyone else been able to reproduce the problem?

>>>Joe Ervin