Thank you.  I see what you mean:  the get_wch() method looks as if it's
applicable to ncurses and all PDCurses... in other words,  pretty much
everything.  The SP->key_code method,  and the method Florian and I used
in Win32a,  will only work in PDCurses.  (Unless we persuaded the ncurses
people to change their ways.  And even then,  you'd have the old libraries
out there.  So get_wch() wins.)

   I don't see much need to revise my code,  but I'll add a note to
the effect that "while this works,  you're better off using get_wch() and
checking the return value."

-- Bill

On 04/08/2015 06:28 PM, William McBrine wrote:
On Wed, Apr 8, 2015 at 5:17 PM, Bill Gray <pl...@projectpluto.com> wrote:


    Incidentally,  you'll also see that in the Win32a version of 'curses.h',
the return values are relative to KEY_OFFSET.  The reason for this is that
PDCurses' "usual" values assume a non-wide version,  and they start at
0x100.  Try making a Unicode build,  and there will be collisions:  if you
get,  say, 0x16B,  did your user hit KEY_MESSAGE,  or an 's with acute
accent'?


Florian Gro├če-Coosmann wrote to me about this a while back. Here's what I
said then:

It's not necessary to relocate the key definitions in order to distinguish
the control keys from regular Unicode input. One must simply use get_wch()
instead of getch(), and check the return value (KEY_CODE_YES or OK), as
well as the character result (which is placed at the location given by the
parameter).

Alternatively, if you don't care about using standard curses wide-character
functions, you can continue using getch(), but check the PDCurses-specific
SP->key_code to determine whether or not the result is a "special" key.
However, I recommend get_wch().

These capabilities date to 2006, BTW.

Reply via email to