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.
