>> Is there any particular character encoding associated with PDCurses?
No. In the case you're talking about, the input comes from ReadConsoleInput(). It's Windows itself that determines the active console code page. (The tables in win32/pdckbd.c are all just for things like ALT and function keys.) You could set it to a so-called ANSI page if you wanted.
Thank you; this does clear things up. With a little experimenting, this is all starting to making sense to me. With the current Win32 scheme, it looks as if one could switch to, say, Russian, and have Russian text entered and displayed. In theory, my Win32a version should be able to do the same thing. After which, I think the only internationalization issue would be bi-directional text for Hebrew, Arabic, etc. I'll leave that problem for another day.
The exception is if you're using the WIDE build. In that case, you always get Unicode. That's actually what I'd recommend.
I'm increasingly seeing why. Handling 8-bit chars has all sorts of strange nuances to it I'd not fully appreciated before. Though I think, between your replies and some testing at my end, I'm seeing how to get all this to work... it'll probably result in an update to Win32a in the next few days. > I should add, there is one issue with this: The box-drawing > characters. In the Win32 console port, these are defined in terms of > CP437 -- both because that's the default console code page (for the > U.S.), and because there aren't any box-drawing characters in the > "ANSI" code pages. But this problem is obviated if you use the WIDE > build. Also obviated in Win32a. If the A_ALTCHARSET flag is set, we know to show a suitable Unicode character. The actual display of text is handled using TextOutW (wide-char function) even in the non-WIDE build. So at least I don't have that problem to fix as well. Thanks! -- Bill
