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.