KEY , EKEY , AND EKEY>CHAR 
Author Message
 KEY , EKEY , AND EKEY>CHAR

I think I understand that different EKEY events may become
the same char with EKEY>CHAR.

May one assume that KEY and EKEY will return the same char
from the same KEY event?

Or must one always write:

EKEY EKEY>CHAR

to be sure of getting decimal 65 after A is pressed?

This latter would be a pain if one is trying to write a
Standard program that allows either KEY or EKEY, since KEY
and EKEY EKEY>CHAR have different stack effects.  One would
have to write key handlers for both KEY and EKEY.

It would be much easier if EKEY and KEY returned the same
u's for KEY events while KEY silently discarded non-KEY
events as the Standard says it should and EKEY produced from
these events u's that were outside the range of the KEY u's.

Is there any reason why one might not want a Standard system
to do this?

Leo Wong
--

http://www.*-*-*.com/ ~hello/



Sat, 06 Nov 1999 03:00:00 GMT  
 KEY , EKEY , AND EKEY>CHAR


Quote:

>I think I understand that different EKEY events may become
>the same char with EKEY>CHAR.

Yes.

Quote:
>May one assume that KEY and EKEY will return the same char
>from the same KEY event?
>Or must one always write:
>EKEY EKEY>CHAR
>to be sure of getting decimal 65 after A is pressed?

The latter.

Quote:
>This latter would be a pain if one is trying to write a
>Standard program that allows either KEY or EKEY, since KEY
>and EKEY EKEY>CHAR have different stack effects.  One would
>have to write key handlers for both KEY and EKEY.

EKEY does whatever it does on the particular system.  Here's one
possibility:  it might return some sort of event code, perhaps it
reports the keystroke according to the OS coding, maybe including a
bit to say whether a shift key was pressed and which shift key.  That
gives you 3 different EKEY things that would all return A after
EKEY>CHAR when the capslock key is not active.

Quote:
>It would be much easier if EKEY and KEY returned the same
>u's for KEY events while KEY silently discarded non-KEY
>events as the Standard says it should and EKEY produced from
>these events u's that were outside the range of the KEY u's.
>Is there any reason why one might not want a Standard system
>to do this?

You might want to be able to tell which shift key the user pressed etc.
You can't use that in a standard way, since systems vary.  But the
standard doesn't say a system can't do that.

You can get the result you want easily, provided you accept one small
environmental dependency -- namely that the result of EKEY for
keystrokes that don't give ANSI characters must be outside the range
32-126.  In that case you can do:

: MY-EKEY ( -- char|u )
   EKEY EKEY>CHAR DROP ;



Sun, 07 Nov 1999 03:00:00 GMT  
 KEY , EKEY , AND EKEY>CHAR

   >May one assume that KEY and EKEY will return the same char
   >from the same KEY event? Or must one always write: EKEY EKEY>CHAR
   >to be sure of getting decimal 65 after A is pressed?
One must always write EKEY EKEY>CHAR. EKEY could return 923867102
for 'A and 23646 for 'B and 5 for 'C for all the standard cares. But
EKEY>CHAR would have to be able to convert these numbers into the
appropriate characters, ie 65, 66, and 67.

   >This latter would be a pain if one is trying to write a
   >Standard program that allows either KEY or EKEY, since KEY
   >and EKEY EKEY>CHAR have different stack effects.  One would
   >have to write key handlers for both KEY and EKEY.
: ekeyer   ekey ekey>char
  if  do-the-key  else  do-the-ekey  then ;
: keyer   key do-the-key ;
: handle-any-key  use-ekey? if  ekeyer  else  keyer  then ;

Is the first solution I though of, ie., definetely not the best. :)

Another thing, by the way. I found a bug in LF. When you load a file
and you have the number of total screen columns set to greater than
73 (ie., 74 and up) it'll load garbage for some weird reason into the
beginning of the file. For instance, in LF, try setting TABWIDTH to
say, 2, and TABS/LINE to 38.  When you load up a file, you'll see some
garbage at the start of it, and it'll save it out with the garbage too!
I can't figure it out, but I know it DOESN'T happen in MF, only with LF.
This bug occurs in all the systems I've tried LF on, my For32, Hforth,
and Gforth.




Tue, 09 Nov 1999 03:00:00 GMT  
 KEY , EKEY , AND EKEY>CHAR


Quote:
> I think I understand that different EKEY events may become
> the same char with EKEY>CHAR.

> May one assume that KEY and EKEY will return the same char
> from the same KEY event?

> Is there any reason why one might not want a Standard system
> to do this?

Well, the standard system could want to return the keycodes of the
keyboard, or the event codes of the X Window system. These are not
necessarily the same as the ASCII encodings, and may overlap with
them.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Sun, 14 Nov 1999 03:00:00 GMT  
 KEY , EKEY , AND EKEY>CHAR


Quote:


> > I think I understand that different EKEY events may become
> > the same char with EKEY>CHAR.

> > May one assume that KEY and EKEY will return the same char
> > from the same KEY event?

> > Is there any reason why one might not want a Standard system
> > to do this?
> Well, the standard system could want to return the keycodes of the
> keyboard, or the event codes of the X Window system. These are not
> necessarily the same as the ASCII encodings, and may overlap with
> them.

        Exactly. Early on in their development, Commodore went from
Capitals + Graphics characters on shift to Lower and Upper case by leaving
the key codes alone and switching to a different graphic character set
definition.  This was around the time ASCII was finalized, but they ended
up with the lower and upper case codes reversed (as well as a collection
of other non-ASCII characters in the 32-127 block as well).  If Forth is
going to support the programming of the system, two different ways to view
keyboard events are needed:
        What will give standard Forth programs what they expect to see?
        What will give direct access to what is actually going on?
Evidently, KEY is the former and EKEY is the later.  EKEY events 32-128
are never entirely ASCII: either the case is reversed, or the case is
right but the lower case is replaced by graphic characters.
        If the standardevents returned by KEY are insufficient, what is
needed is an expanded set of standard events that can be translated from
EKEY.  If EKEY is turned into some kind of KEY+extra info, it will be
necessary to invent a new EKEY for a direct stack interface for system
keyboard events.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Mon, 15 Nov 1999 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. EKEY>CHAR in Win32Forth

2. KEY and EKEY

3. portable definitions for KEY and EKEY?

4. KEY and EKEY

5. Key and EKey

6. IDLE-EKEY?

7. EKEY in gforth in DOS

8. EKEY in gforth for linux?

9. EKEY and double numbers

10. EKEY part 3 of 3

11. EKEY part 2 of 3

12. EKEY part 1 of 3

 

 
Powered by phpBB® Forum Software