Prev: Calling Libraries from SysRPL
Next: Stephen Wolfram's book, "A New Kind of Science" gives us three (3) very important facts:
From: PremiumBlend on 11 Jul 2010 00:49
Hello,

I don't understand how to use the KEY command
in a program. In the following program I would like
the row and column of the YES or NO key returned:

\<< { { "YES"} " " " " " " " " { "NO"} } TMENU \>> .

I thought this would work:

\<< { { "YES"
\<< KEY
\>> } " " " " " " " " {
"NO"
\<< KEY
\>> } } TMENU .

Also, is it possible to use the KEY command to
determine if the user has pressed the CANCEL
key to terminate the INPUT command? I normally
use \<< IFERR INPUT THEN ... ELSE ... END \>>
but I was thinking if KEY returns:

2: @ row column
1: 1

then \<< \<< @ Was CANCEL or ENTER pressed?
\>> IFT \>> .

By the way, what is the row column of the CANCEL
key? I mean the row is 10 and the column is 1 so
would it be 101.0 or 101.1?

Regards,

Mark
From: Han on 11 Jul 2010 01:44
KEY is a command that returns the keycode IF there was a key combo
that was being held down right as the KEY command gets executed. It is
best used within a loop. E.g. << DO KEY UNTIL END >>

What you probably want to do is use the WAIT key. E.g. << IFERR 0.
WAIT THEN "ON PRESSED" END >>

Using a non-zero argument for WAIT will result in a different effect
-- the program will simply "wait" for that many seconds.

Han
From: John H Meyers on 11 Jul 2010 18:10
On 7/10/2010 11:49 PM, PremiumBlend wrote:

> I don't understand how to use the KEY command

KEY tells you whether there is an as yet _unprocessed_ keypress
in the key buffer, i.e. a single key that's been pressed,
but has not been recognized or acted on, since your program started,
and returns the key number if so.

You can see the action of KEY by running this program,
which loops until you press a key,
returning the key number:

\<< DO UNTIL KEY END \>> 'key' STO

However, the ON/CANCEL key aborts this program, as usual,
rather then returning any actual key number.

> In the following program I would like
> the row and column of the YES or NO key returned:
>
> \<< { { "YES"} " " " " " " " " { "NO"} } TMENU \>>

Since TMENU simply sets up a menu, but does not wait
for anything to be pressed, that program simply
sets up a menu and then terminates.

The "System Outer Loop" is then itself waiting for keypresses
and taking action on them. In so doing, any pressed menu key
is already removed from the key buffer and interpreted
before the system executes any function associated with the key,
so it's too late to invoke the KEY command within any of those
menu key definitions, hoping to catch a keypress
that has already been processed by the system itself.

On the other hand:

\<< { { "YES" 1 } {} {} {} {} { "NO" 2 } } TMENU \>>

This creates a menu
which generates any desired results on the stack when keys are pressed,
and which also properly specifies "dead" (inactive) keys.

> Also, is it possible to use the KEY command to
> determine if the user has pressed the CANCEL
> key to terminate the INPUT command? I normally
> use \<< IFERR INPUT THEN ... ELSE ... END \>>

Use what you "normally" do, since the only condition
(barring running completely out of memory) which causes
the INPUT command to "error" is pressing CANCEL.

Actually, pressing CANCEL is first trapped within INPUT itself,
and merely clears the edit buffer if that buffer is not
already empty, aborting only if the edit buffer
is completely empty at the point where CANCEL is pressed.

> By the way, what is the row column of the CANCEL
> key? I mean the row is 10 and the column is 1 so
> would it be 101.0 or 101.1?

Since you can't disable CANCEL from aborting UserRPL,
the theoretical KEY result of 101
and the theoretical -1 WAIT result of 101.1
are somewhat moot :)

However, here's a SysRPL program
for capturing "complete" key sequences
(absorbing "shifts" into "keyplanes"),
which will return 101.1 (plus other results):

"::
CK0NOLASTWD
BlankDA2
"Complete a keypress.."
DISPROW5
WaitForKey
2DUP
Key>U/SKeyOb
UNROT
OVERSWAP
CodePl>%rc.p
;"

[r->] [OFF]
From: PremiumBlend on 12 Jul 2010 17:53
On Jul 11, 1:44 am, Han <handuongs...(a)gmail.com> wrote:
> KEY is a command that returns the keycode IF there was a key combo
> that was being held down right as the KEY command gets executed. It is
> best used within a loop. E.g. << DO KEY UNTIL END >>
>
> What you probably want to do is use the WAIT key. E.g. << IFERR 0.
> WAIT THEN "ON PRESSED" END >>
>
> Using a non-zero argument for WAIT will result in a different effect
> -- the program will simply "wait" for that many seconds.
>
> Han

Thanks!
From: PremiumBlend on 12 Jul 2010 17:53
On Jul 11, 6:10 pm, John H Meyers <jhmey...(a)nomail.invalid> wrote:
> On 7/10/2010 11:49 PM, PremiumBlend wrote:
>
> > I don't understand how to use the KEY command
>
> KEY tells you whether there is an as yet _unprocessed_ keypress
> in the key buffer, i.e. a single key that's been pressed,
> but has not been recognized or acted on, since your program started,
> and returns the key number if so.
>
> You can see the action of KEY by running this program,
> which loops until you press a key,
> returning the key number:
>
> \<< DO UNTIL KEY END \>> 'key' STO
>
> However, the ON/CANCEL key aborts this program, as usual,
> rather then returning any actual key number.
>
> > In the following program I would like
> > the row and column of the YES or NO key returned:
>
> > \<<  { { "YES"} " "  " "  " "  " " { "NO"} } TMENU \>>
>
> Since TMENU simply sets up a menu, but does not wait
> for anything to be pressed, that program simply
> sets up a menu and then terminates.
>
> The "System Outer Loop" is then itself waiting for keypresses
> and taking action on them.  In so doing, any pressed menu key
> is already removed from the key buffer and interpreted
> before the system executes any function associated with the key,
> so it's too late to invoke the KEY command within any of those
> menu key definitions, hoping to catch a keypress
> that has already been processed by the system itself.
>
> On the other hand:
>
> \<<  { { "YES" 1 } {} {} {} {} { "NO" 2 } } TMENU \>>
>
> This creates a menu
> which generates any desired results on the stack when keys are pressed,
> and which also properly specifies "dead" (inactive) keys.
>
> > Also, is it possible to use the KEY command to
> > determine if the user has pressed the CANCEL
> > key to terminate the INPUT command? I normally
> > use \<<  IFERR INPUT THEN ... ELSE ... END \>>
>
> Use what you "normally" do, since the only condition
> (barring running completely out of memory) which causes
> the INPUT command to "error" is pressing CANCEL.
>
> Actually, pressing CANCEL is first trapped within INPUT itself,
> and merely clears the edit buffer if that buffer is not
> already empty, aborting only if the edit buffer
> is completely empty at the point where CANCEL is pressed.
>
> > By the way, what is the row column of the CANCEL
> > key? I mean the row is 10 and the column is 1 so
> > would it be 101.0 or 101.1?
>
> Since you can't disable CANCEL from aborting UserRPL,
> the theoretical KEY result of 101
> and the theoretical -1 WAIT result of 101.1
> are somewhat moot :)
>
> However, here's a SysRPL program
> for capturing "complete" key sequences
> (absorbing "shifts" into "keyplanes"),
> which will return 101.1 (plus other results):
>
> "::
>    CK0NOLASTWD
>    BlankDA2
>    "Complete a keypress.."
>    DISPROW5
>    WaitForKey
>    2DUP
>    Key>U/SKeyOb
>    UNROT
>    OVERSWAP
>    CodePl>%rc.p
> ;"
>
> [r->] [OFF]

Thanks!
 | 
Pages: 1
Prev: Calling Libraries from SysRPL
Next: Stephen Wolfram's book, "A New Kind of Science" gives us three (3) very important facts: