KEY and EKEY 
Author Message
 KEY and EKEY

I've got a full copy of the ANS document in front of me but I am still
uncertain about the TC's intention regarding KEY and EKEY. I understand
that the job of EKEY is to return characters (or more complex data
records) to indicate keyboard events which are beyond the range of KEY.

I am interested in characters 0 to 31 and 127. As I read the document,
these characters will be returned by KEY if they are part of the
"implementation-defined character set" and by EKEY if not. (My
implementation prints the same graphic for all these characters.)

I plan to define the character set for this implementation as 32 to 126
- the printable characters. KEY will return only these and EKEY must be
used to retrieve everything else. This seems a simple definition but it
is rather different from the example in the ANS document, which uses KEY
to retrieve the characters 0-31.

Will I come to regret this decision, I wonder?

--
Bye for now
                                         ____/  /  __  /   /   /   /   /
Chris Jakeman                           /      /  /  _/   /   /   /  /
                                       __/    /  / __    /   /   /_/
                                      /      /  /   /   /   /   /  \
                                   __/    __/  ____/    ___/ __/   _\

                           Forth Interest Group United Kingdom Chapter
Voice +44 (0)1733 753489   at www.users.zetnet.co.uk/aborigine/forth.htm



Wed, 21 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:

> I've got a full copy of the ANS document in front of me but I am still
> uncertain about the TC's intention regarding KEY and EKEY. I
understand
> that the job of EKEY is to return characters (or more complex data
> records) to indicate keyboard events which are beyond the range of
KEY.

> I am interested in characters 0 to 31 and 127. As I read the document,
> these characters will be returned by KEY if they are part of the
> "implementation-defined character set" and by EKEY if not. (My
> implementation prints the same graphic for all these characters.)

> I plan to define the character set for this implementation as 32 to
126
> - the printable characters. KEY will return only these and EKEY must
be
> used to retrieve everything else. This seems a simple definition but
it
> is rather different from the example in the ANS document, which uses
KEY
> to retrieve the characters 0-31.

> Will I come to regret this decision, I wonder?

In my systems, EKEY returns any event -- keystroke, pen movement, etc.
EKEY>CHAR translates keystroke events into characters; KEY uses
EKEY>CHAR to wait for the next keyboard event.

In a system that only has keystroke events, I'd let EKEY and KEY both
return all keystrokes.

--
Neal Bridges
<http://www.interlog.com/~nbridges/> Home of the Quartus Forth compiler!

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Fri, 23 Nov 2001 03:00:00 GMT  
 KEY and EKEY


Quote:
> I've got a full copy of the ANS document in front of me but I am still
> uncertain about the TC's intention regarding KEY and EKEY. I understand
> that the job of EKEY is to return characters (or more complex data
> records) to indicate keyboard events which are beyond the range of KEY.

> I am interested in characters 0 to 31 and 127. As I read the document,
> these characters will be returned by KEY if they are part of the
> "implementation-defined character set" and by EKEY if not. (My
> implementation prints the same graphic for all these characters.)

As I read the document, EKEY returns keyboard events in an arbitrary
encoding; e.g., the keyboard even corresponding to pressing and
releasing "a" may be 4783.  If you then do

4783 ekey>char

you should get "97 true".

Quote:
> I plan to define the character set for this implementation as 32 to 126
> - the printable characters. KEY will return only these and EKEY must be
> used to retrieve everything else.

IMO the right thing to do is to have key return anything that can be
represented as a single character in the character set, whereas EKEY
should be able to deal with this, and with other stuff, such as
function keys, cursor keys, etc.

I wonder about one thing, though: X delivers events for the keypress
and the key release, and events for shift keys.  Is the intention for
EKEY to deliver events for every such event?  Or should EKEY be higher
level, and just tell the program that the user just pressed
Ctrl-Alt-X? If the former, how do I get EKEY>CHAR to produce "X"
instead of an untranslatable shift key and an "x"?

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

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



Fri, 23 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:

> IMO the right thing to do is to have key return anything that can be
> represented as a single character in the character set, whereas EKEY
> should be able to deal with this, and with other stuff, such as
> function keys, cursor keys, etc.

IOW, KEY EMIT must print a single character. That can usually be
assummed for codes 32-127, but some machines trap some of the lesser
codes for their own purposes. So any program that depends on a KEY value
less than 32 is implementaton-dependent.

There's a lot of old code around with phrases like:

  BEGIN do-something KEY 13 = UNTIL

Quote:
> I wonder about one thing, though: X delivers events for the keypress
> and the key release, and events for shift keys.  Is the intention for
> EKEY to deliver events for every such event?  Or should EKEY be higher
> level, and just tell the program that the user just pressed
> Ctrl-Alt-X? If the former, how do I get EKEY>CHAR to produce "X"
> instead of an untranslatable shift key and an "x"?

I'd say the latter. An 'event' is just a way of telling a program that
something has happen in which it should be interested. How exactly that
event was produced is a matter for the user interface.  For example, a
'page-down' may be produced by a Page-Down key, or by a click in a
scroll bar.  The only stipulation for EKEY is that it should recognize
key-presses corresponding to characters, and allow the key-codes to be
retrieved using EKEY>CHAR

  Shift-X       EKEY EKEY>CHAR should produce "X true"
Contorl-Shift-X need not produce a return from EKEY, and if it does, it
should probably be  "u false".

Since the codes returned by EKEY vary from one implentation or another,
it would seem best to represent them by names, perhaps of defining words
of the form:

: EVENT  \ x1 xn -- ; set up the data to test for an event
DOES>    \ u -- true | u false ; u is produced by EKEY

And by this means declare the events in which the program is interested
at the start.
--
Jack Brien
http://www.users.zetnet.co.uk/aborigine/forth.htm
Home of the FigUK website



Fri, 23 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:

>As I read the document, EKEY returns keyboard events in an arbitrary
>encoding; e.g., the keyboard even corresponding to pressing and
>releasing "a" may be 4783.  If you then do

>4783 ekey>char

>you should get "97 true".

>> I plan to define the character set for this implementation as 32 to 126
>> - the printable characters. KEY will return only these and EKEY must be
>> used to retrieve everything else.

>IMO the right thing to do is to have key return anything that can be
>represented as a single character in the character set, whereas EKEY
>should be able to deal with this, and with other stuff, such as
>function keys, cursor keys, etc.

>I wonder about one thing, though: X delivers events for the keypress
>and the key release, and events for shift keys.  Is the intention for
>EKEY to deliver events for every such event?  Or should EKEY be higher
>level, and just tell the program that the user just pressed
>Ctrl-Alt-X? If the former, how do I get EKEY>CHAR to produce "X"
>instead of an untranslatable shift key and an "x"?

EKEY is a standard way to obtain information that is inherantly
platform-dependent.  It is probably impossible to write a portable
application that uses EKEY.  Windows presents a similar conundrum.  You must
strive to strike a balance, delivering useful information (as opposed to the
low-level sub-events that make up the event).  Unfortunately, you have to
read the mind of the app writer to know what the app considers "useful."  No
easy answers.

Sorry,
Elizabeth



Sat, 24 Nov 2001 03:00:00 GMT  
 KEY and EKEY
Quote:

>As I read the document, EKEY returns keyboard events in an arbitrary
>encoding; e.g., the keyboard even corresponding to pressing and
>releasing "a" may be 4783.  If you then do

>4783 ekey>char

>you should get "97 true".

This sounds like the IBM-PC BIOS interrupt 21H function 06H.  This
returns a flag and key value,  the flag indicating if a key is ready.
If it does find a key ready it is _cleared from the BIOS_.

It is in contrast to function 0BH which does not clear the key from the
BIOS.  You need to know which you want.

I found these distinctions when looking for a way to use CTRL-C in
Pygmy.  I had to re-write KEY and to prevent CTRL-C acting as a Break
and dropping me out of Pygmy.  The solution for me was to use Function
06H.  But that does clear the key from the BIOS.

--
Bill Powell.    Chartered Engineer  <http://www.mrv5.demon.co.uk>
    (Broadband Video, Data & Telecommunications)
        Atherstone, Warks., UK,  CV9 3AR.
        Tel: +44 1827-718 945   |  Fax:         -714 884



Sat, 24 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:

>I've got a full copy of the ANS document in front of me but I am still
>uncertain about the TC's intention regarding KEY and EKEY. I understand
>that the job of EKEY is to return characters (or more complex data
>records) to indicate keyboard events which are beyond the range of KEY.

KEY is guaranteed to work for ASCII.  If you use KEY and the final user
restricts his input to plain ASCII then nothing too strange will happen
unless you program it to do something strange.

EKEY doesn't give you any guarantees.  If you want an input that isn't
ASCII then use EKEY and when somebody has to port your program later
the EKEY will be a red flag, they might have to change things around
right at that point.  It wasn't possible to standardise everything you
might want to do for input, and it didn't seem right to have a standard
that restricted all input to plain ASCII.  So we have both, one is
limited and standard (actually an implementor can extend KEY as far as
he wants to) and the other is a convenient hook for whatever you do
that's hard to make portable.

Quote:
>I am interested in characters 0 to 31 and 127. As I read the document,
>these characters will be returned by KEY if they are part of the
>"implementation-defined character set" and by EKEY if not. (My
>implementation prints the same graphic for all these characters.)

EKEY will return *something* for most of them.  Of course some keystroke
combinations might get trapped by the OS so you'll never see them and
there's nothing you or your Forth system can do about it.

An application programmer can't be quite sure what EKEY will return on
other systems.  

For some applications it would make sense to have a table of special
keystrokes, or a list of constants in one place, and everywhere else
use the names.  Then if you need to change the keystrokes you can do
it easily.

Quote:
>I plan to define the character set for this implementation as 32 to 126
>- the printable characters. KEY will return only these and EKEY must be
>used to retrieve everything else. This seems a simple definition but it
>is rather different from the example in the ANS document, which uses KEY
>to retrieve the characters 0-31.

That's only an example.

Quote:
>Will I come to regret this decision, I wonder?

It depends on what you want to port to.  If you write applications that
depend on this, you could run into various problems porting them.  Some
of 0-31 are likely to be trapped.  Cntl-C for example may be.  And if
your program gets incorporated into a larger one that uses EKEY for
mouse clicks etc, every time you execute EKEY you'll be grabbing those.
Say your routine is waiting for an EKEY but the user wants to move his
mouse and click on something.  EKEY grabs the first mouse event.  Your
program finds out that isn't anything it's looking for.  Does it somehow
pass it to the routine that wants it, or does it throw it away?  

You could at that point make a new EKEY , one that first passes events
to the sophisticated routines and then if they don't want them, gives
it to you and exits.  Then you have two layers that might hide your
keystrokes from you.

It's just hard to legislate.  For non-ASCII characters you can do
pretty much whatever you want and still call it standard.  If your
implementation restricts KEY to just 32-126 then you'll be warning
users when they try to use KEY for things that might not port.  
That's a value.  Your using EKEY in a straightforward way probably
gives them maximal portability because there's a reasonable chance
that other implementors will do the same thing.  No guarantees.



Sun, 25 Nov 2001 03:00:00 GMT  
 KEY and EKEY
On Tue, 8 Jun 1999 10:22:07 -0700, "Elizabeth D Rather"

Quote:

>EKEY is a standard way to obtain information that is inherantly
>platform-dependent.  It is probably impossible to write a portable
>application that uses EKEY.  Windows presents a similar conundrum.  You must
>strive to strike a balance, delivering useful information (as opposed to the
>low-level sub-events that make up the event).  Unfortunately, you have to
>read the mind of the app writer to know what the app considers "useful."  No
>easy answers.

        One way to handle it portably may be a training system, which
prompts for the desired key, and then stores the value returned by
EKEY for later use.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Mon, 26 Nov 2001 03:00:00 GMT  
 KEY and EKEY


Quote:
>  It is probably impossible to write a portable
> application that uses EKEY.

Why standardize it, then?

But given the rareness of complaints about the absence of EKEY from
Gforth, you are probably right.

Bruce McFarling's training approach looks like a portable use of EKEY,
though.

Quote:
>  You must
> strive to strike a balance, delivering useful information (as opposed to the
> low-level sub-events that make up the event).  Unfortunately, you have to
> read the mind of the app writer to know what the app considers "useful."

Yes, but that's because the standard fails to define it well enough.
Otherwise both the implementor and the app programmer would know what
to expect; if the definition was not useful for all apps, tough luck
for the rest, but the current weak definition is, as you write, not
useful for any app.

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

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



Tue, 27 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:



>>  It is probably impossible to write a portable
>> application that uses EKEY.

>Why standardize it, then?

There was demand (though not from me) to be able to get at the "raw
data" for a "keyboard event,"  thinking of function keys, etc.

Quote:
>>  You must
>> strive to strike a balance, delivering useful information (as opposed to
the
>> low-level sub-events that make up the event).  Unfortunately, you have to
>> read the mind of the app writer to know what the app considers "useful."

>Yes, but that's because the standard fails to define it well enough.
>Otherwise both the implementor and the app programmer would know what
>to expect; if the definition was not useful for all apps, tough luck
>for the rest, but the current weak definition is, as you write, not
>useful for any app.

The more well-defined it is, the less "raw", so as you make one group
happy another gets upset.  Such are the joys of writing Standards.  In
it's present form, it's probably very useful to many apps, but they are
not entirely portable.  However, if all you have to do is change what
the event you're looking for returns, I guess it's better than having to
change the logic of your program.

Cheers,
Elizabeth



Tue, 27 Nov 2001 03:00:00 GMT  
 KEY and EKEY
On Fri, 11 Jun 1999 15:13:39 -0700, "Elizabeth D Rather"

Quote:




>>>  It is probably impossible to write a portable
>>> application that uses EKEY.

>>Why standardize it, then?

?F happily uses EKEY.  I was able to choose between Win32Forth and
SwiftForth.  I'm glad EKEY is there, at least for these programs.

Leo Wong

http://www.albany.net/~hello/
The Forth Ring: http://zForth.com



Wed, 28 Nov 2001 03:00:00 GMT  
 KEY and EKEY


Quote:



> >>  You must
> >> strive to strike a balance, delivering useful information (as opposed to
> the
> >> low-level sub-events that make up the event).  Unfortunately, you have to
> >> read the mind of the app writer to know what the app considers "useful."

> >Yes, but that's because the standard fails to define it well enough.
> >Otherwise both the implementor and the app programmer would know what
> >to expect; if the definition was not useful for all apps, tough luck
> >for the rest, but the current weak definition is, as you write, not
> >useful for any app.

> The more well-defined it is, the less "raw", so as you make one group
> happy another gets upset.  Such are the joys of writing Standards.  In
> it's present form, it's probably very useful to many apps, but they are
> not entirely portable.  However, if all you have to do is change what
> the event you're looking for returns, I guess it's better than having to
> change the logic of your program.

Yes, but the problem is that the present definition does not define
what constitutes an event (i.e., what, e.g., X sees as event or
something more high-level), and therefore the application programmer
may have to change the logic of the program when porting between
systems, even though all have a conforming EKEY.

So what I have understood to be the meaning of "event" from your
comments is:

Pressing a non-shift key is a keyboard event; the event code also
encodes the combinations of shift keys pressed at the same time as the
key press. Some keys may produce several events with the same code if
pressed longer (autorepeat).  Releasing a key is not an event;
pressing a shift key is not an event.

Maybe you should put something like that in the standard.

Event constants for frequent keys like the cursor keys would also be
helpful.

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

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



Thu, 29 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:

>Yes, but the problem is that the present definition does not define
>what constitutes an event (i.e., what, e.g., X sees as event or
>something more high-level), and therefore the application programmer
>may have to change the logic of the program when porting between
>systems, even though all have a conforming EKEY.

That's true.  Implementors get to define events to fit their
circumstances and the standard lets them do pretty much whatever they
want that way -- with the single limitation that EKEY returns only
a single cell.  Since that cell could be the address of a table of
data that isn't much of a limitation.

Quote:
>So what I have understood to be the meaning of "event" from your
>comments is:
>Pressing a non-shift key is a keyboard event; the event code also
>encodes the combinations of shift keys pressed at the same time as the
>key press. Some keys may produce several events with the same code if
>pressed longer (autorepeat).  Releasing a key is not an event;
>pressing a shift key is not an event.
>Maybe you should put something like that in the standard.

At this point the standard doesn't say *anything* about what you can do
with the results of EKEY except that you can use EKEY>CHAR and possibly
get a character -- if you do it makes sense you should get the same
character you'd have gotten with KEY .  

I'm not clear that the standard should legislate much about what an
event can be.  It's fine with me if an implementor wants to make
pressing the shift key or releasing another key an event.  If I get
a one-handed chord keyboard or a TV camera that takes pictures of
my hands at a dummy keyboard or whatever, I'll want events to be
whatever I want them to be.  

EKEY looks to me like a grab-bag.  For one thing it lets you do
any kind of data entry you want to and still have a standard program.
If you have a coffee machine hooked up to your parallel port and
the coffee machine tells you about its transactions according to
some code, you can make its reports be events and use EKEY and
you'll have a standard program.  Portable only to other people who
use the same codes, but you can label it standard.

And you can publish your own standard for coffee codes, and anybody
who wants to can use it.

There isn't much common practice for all this in Forth yet, and we
might as well let people do what they want to until we find out
better what they want.  



Thu, 29 Nov 2001 03:00:00 GMT  
 KEY and EKEY

Quote:


>>So what I have understood to be the meaning of "event" from your
>>comments is:

>>Pressing a non-shift key is a keyboard event; the event code also
>>encodes the combinations of shift keys pressed at the same time as the
>>key press. Some keys may produce several events with the same code if
>>pressed longer (autorepeat).  Releasing a key is not an event;
>>pressing a shift key is not an event.

>>Maybe you should put something like that in the standard.

As I noted elsewhere, we welcome proposals...

Quote:
>At this point the standard doesn't say *anything* about what you can do
>with the results of EKEY except that you can use EKEY>CHAR and possibly
>get a character -- if you do it makes sense you should get the same
>character you'd have gotten with KEY .

>I'm not clear that the standard should legislate much about what an
>event can be.  It's fine with me if an implementor wants to make
>pressing the shift key or releasing another key an event.  If I get
>a one-handed chord keyboard or a TV camera that takes pictures of
>my hands at a dummy keyboard or whatever, I'll want events to be
>whatever I want them to be.

The problem is, that if you are an application writer, you have limited
influence over what the implementor decided.  On the other hand,
implementors are usually practical people, and _probably_ will make
useful decisions.

Quote:
>EKEY looks to me like a grab-bag.  For one thing it lets you do
>any kind of data entry you want to and still have a standard program.
>If you have a coffee machine hooked up to your parallel port and
>the coffee machine tells you about its transactions according to
>some code, you can make its reports be events and use EKEY and
>you'll have a standard program.  Portable only to other people who
>use the same codes, but you can label it standard.

Um, no, your program is standard with a dependency on certain
returns from EKEY.  Which probably applies to virtually all programs
that use EKEY.

Quote:
>There isn't much common practice for all this in Forth yet, and we
>might as well let people do what they want to until we find out
>better what they want.

I beg to differ.  There's at least 5 years' experience in many shops.
A lot of people have used it extensively.  There's probably a lot
of useful feedback we could get, which is why the floor is open
for proposals.

Cheers,
Elizabeth



Thu, 29 Nov 2001 03:00:00 GMT  
 KEY and EKEY


Quote:

>There isn't much common practice for all this in Forth yet, and we
>might as well let people do what they want to until we find out
>better what they want.  

Sure, but why standardize its name then? Calling it EKEY when it can
be whatever it wants to, IMHO doesn't help much. On the contrary.

Stefan,
--
Stefan Axelsson                         Chalmers University of Technology

(Remove "rmovt.rply" to send mail.)



Fri, 30 Nov 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. portable definitions for KEY and EKEY?

2. KEY and EKEY

3. Key and EKey

4. KEY , EKEY , AND EKEY>CHAR

5. IDLE-EKEY?

6. EKEY in gforth in DOS

7. EKEY in gforth for linux?

8. EKEY>CHAR in Win32Forth

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