bug#10299: Emacs doesn't handle Unicode characters in keyboard layout on MS Windows

[Joakim Hårsman]

Your patch works fine for me on Windows XP. Unicode input outside the
system code page works fine and so does non-ASCII input that is
present in the current code page.

Since this seems much cleaner than the previous patch, it is
definitely the way to go.

I think the critical change was switching to both DefWindowProcW and
DispatchMessageW (at least that's what
http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/07afec87-68c1-4a56-bf46-a38a9c2232e9/
leads you to believe).

I think I actually tried both those changes individually, but not both at once.

I'll test a patched build on Windows 7 tomorrow as well, sadly I don't
have access to anything running Windows 95.

Thanks for taking the time to look at this and test it.

On 7 August 2012 04:53, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 6 Aug 2012 22:20:01 +0200
>> From: Joakim Hårsman <joakim.harsman@gmail.com>
>> Cc: lekktu@gmail.com, 10299@debbugs.gnu.org
>>
>> Sorry for the late reply, I've been away on vacation.
>
> No sweat.  Hope you had a good one.
>
>> The change to SetWindowTextW for frame titles was needed because
>> otherwise the frame title was cut short after the first character
>> (presumably because the window class name is a UCS-2 wide string and
>> the second byte therefore is null). This is exaclty the case they talk
>> about at your link.
>>
>> If I change w32_set frame text to always call SetWindowText I get a
>> default frame title of "e". Changing DispatchMessage to use the wide
>> version when appropriate doesn't help either.
>
> I didn't see any problem with the frame title, with the patch I sent.
> I'm curious to hear if you will still see that problem.
>
>> I'll try your new patch tomorrow and get back with details on how it worked,
>
> Thank you.