Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #20062

Re: (E)KEY return values problem

Show all headers | View raw

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
>Not sure: is it proper behaviour of EKEY, that it doesn't recognize "just
>any" key-combination?
>
>I would to have available various key-combinations - obvious in many
>situations - but using KEY/EKEY e.g. I get "13" for both <Enter> and
><Shift>-<Enter> (or for <Control>-<Enter>) - a little test in Gforth.

Yes, there are no guarantees that anything is recognized.  This is
pretty much a best-effort thing, and depending on what's between the
keyboard and the Forth system, there may be no way to differentiate
between <Enter> and <Shift>-<Enter>.

E.g., I just tested this in a setup where the keys are pressed on the
keyboard (which has its own CPU and eventually produces keycodes), is
processed by the X Server on the X terminal (possibly it had to go
through the Linux kernel on the X terminal before), which produces
KeyPress and KeyRelease events and translates keycodes into keysyms,
then the events get sent over to the xterm terminal emulator running
on the server that runs Gforth, which translates the X stuff into
stuff a vt100-like terminal would produce, and this is finally what
Gforth sees.  In this case, xterm maps both <Enter> and
<Shift>-<Enter> into 13, so Gforth has no way to report the
difference.

You might write your own terminal emulator (or maybe reconfigure
xterm) to be more discerning, but that's not always practical (in the
extreme, what if a real terminal is connected that does not report the
difference?), so prepare your programs not to rely on being able to
recognize the difference.

> On the
>other hand: <Shift>-<PgUp> and <Shift>-<PgDn> are ignored by KEY / EKEY.

On my xterm these combinations are caught by the xterm and not
forwarded to the application; they are interpreted as scrolling
commands.

>Fortunately, EKEY seems to allow recognition of many key-combinations - like
><Shift>-<Home>, <Control>-<Home> (the result is different) - but shouldn't
>it work for just all of them? Well, maybe not necessarily e.g. 3 letter-keys
>pressed at the same time - but at least all <key>-<key-modifier> combinations
>("key-modifiers": shift, alt, windows-key, control - left and right ones
>recognized separately)?

Sure, that would be nice, but it's not realistic.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

(E)KEY return values problem Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-25 23:12 +0100
  Re: (E)KEY return values problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-27 15:02 +0000
    Re: (E)KEY return values problem Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-27 20:49 +0100
      Re: (E)KEY return values problem Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 00:27 +0100
        Re: (E)KEY return values problem Rob Sciuk <rob@controlq.com> - 2013-02-28 13:05 -0500
      Re: (E)KEY return values problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:04 +0000

csiph-web