[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19994: 25.0.50; Unicode keyboard input on Windows
From: |
Ilya Zakharevich |
Subject: |
bug#19994: 25.0.50; Unicode keyboard input on Windows |
Date: |
Thu, 5 Mar 2015 16:43:32 -0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Mar 04, 2015 at 08:01:01PM +0200, Eli Zaretskii wrote:
> > +static int
> > +get_wm_chars (HWND aWnd, int *buf, int buflen, int ignore_ctrl, int ctrl,
> > int
> ^^^^^^^^
> Why 'int' and not 'wchar_t'?
This is for a Unicode chars. They won’t fit into (Windows’ style) wchar_t.
> > + while (buflen && /* Should be called only
> > when w32_unicode_gui */
> > + PeekMessageW(&msg, aWnd, WM_KEYFIRST, WM_KEYLAST, PM_NOREMOVE |
> > PM_NOYIELD) &&
>
> Indeed, any "wide" APIs should only be called when w32_unicode_gui is
> on, and there should be alternative code for when w32_unicode_gui is
> off. We still try to support Windows 9X.
The caller ensures this. Yes, assert() would be beneficial here.
> > + int ctrl_cnt, buf[1024], count, is_dead;
>
> I think buf[] should be an array of wchar_t. Also, will this code
> work for the non-w32_unicode_gui mode?
This code is pure-GUI. For non-GUI “bindable” input on Windows the
major hurdle is that
(A) I know no way to distinguish a “prefix key” (deadkey) keypress
from a keypress which should trigger user bindings;
(B) with “non-destructive ToUnicode()”, one WOULD be able to
distinguish these two cases, — but I have no clue how to find
out the current keyboard layout of a console session.
(There is a lot of examples of code which returns the keyboard
layout of a window; — but these examples do not work for
console sessions. I suppose that the reason is that the window
is actually owned by a system process, and one does not have
permissions to access its properties.)
Thanks,
Ilya