We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

SDL_TEXTINPUT system doesn't handle key sequences correctly on Windows due to the usage of both TranslateMessage and ToUnicode to handle WM_KEY* messages.

In my keyboard layout, pressing single quote character ('), followed by certain letters (acegksu..) outputs language-specific variations of those letters (āčēģķšū..). This is the software I use that provides this layout: http://laacz.lv/f/misc/apos/apostrofs-punkts.zip - it can be used to verify the bug and check if it's been fixed.

From what I've seen while experimenting with this code - https://www.dropbox.com/s/ydkrms6zgaxueb8/winchar.c - it works if either TranslateMessage is called or ToUnicode(Ex) is called, but not both.


Quote from http://msdn.microsoft.com/en-us/library/windows/desktop/ms646322(v=vs.85).aspx (ToUnicodeEx page):

As ToUnicodeEx translates the virtual-key code, it also changes the state of the kernel-mode keyboard buffer. This state-change affects dead keys, ligatures, alt+numpad key entry, and so on. It might also cause undesired side-effects if used in conjunction with TranslateMessage (which also changes the state of the kernel-mode keyboard buffer).


So far the solution seems simple. However, it appears there must be a reason for why WM_CHAR messages are not used. The reason for TranslateMessage was given in comments: compatibility with other systems.

For my use case (https://github.com/snake5/sgs-sdl) it would be completely acceptable to include an optional solution in the form of an API function that disables either function call to make it work. For compatibility with other systems, possibly the usage of WM_KEYDOWN/ToUnicode instead of WM_CHAR/TranslateMessage should be reconsidered.