Re: unexpected behavior of ACCEPT

The default KEY? handler stuffs the key into a variable which KEY
retrieves from. So, the key will not be available to ACCEPT.

For this example, you can work around it like this:

>> : q2 10000 ms key? if pad 10 accept pad swap dump then ;

: q3 ( -- ) 10000 ms key? if
       key dup emit pad c! pad 1+ 9 accept pad swap 1+ dump
    then ;

I don't do much with SwiftForth (usually, just SwiftX) so take this
for what it's worth...namely, a generic Forth style tip:

Usually, you don't call ACCEPT unless you're willing to block
waiting on input. ACCEPT's purpose in life is to get a *line* of
text from the user. That's what your SwiftForth interpreter uses to
get a line from you in the console window.

If you need to assure you don't block (presumably because you have
to do something else between keystrokes,) a loop using KEY? and KEY
is probably more appropriate. More likely than not, using KEY and
ACCEPT the way you are above means that you won't get all the input
that the user is trying to provide. Also, the input via KEY won't
be subject to the line editing that input via ACCEPT is.

--
Ron Oliver <ron_at_openesque.com>
----------------------------------------------------------------------
sftalk_at_forth.com      The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users.  For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------