How can I use ToUnicode without breaking dead key support?

Question

A similar question has already been asked, so I'm not going to waste time re-explaining it, an existing discussion can be found here: http://stackoverflow.com/questions/1964614/toascii-tounicode-in-a-keyboard-hook-destroys-dead-keys

The reason I'm posting a new question however is that I seem to have come across a 'solution', but I'm not quite sure how to implement it.

This blog post seems to propose a solution to the problem of ToUnicode killing dead-key support: http://blogs.msdn.com/michkap/archive/2005/01/19/355870.aspx

However I'm not sure how to implement the suggested solution. A push in the right direction would be greatly appreciated.

To be clear, the part I'm referring to is this:

There are two ways to work around this:

1) You can keep calling ToUnicode with the same info until it is cleared out and then call it one more time to put the state back where it was if you had never typed anything, or

2) You can load all of the keyboard info ahead of time and then when they type information you can look up in your own info cache what the keystrokes mean, without having to call APIs later.

I'm not quite sure how to do either of those things (keyboards and internationalization are far from my strong point), so any help would be greatly appreciated.

Thanks

Answer 1

The first part of the answer is entirely information-free. However, the second part does make sense. ToUnicode() should have been a pure function, which merely acts as a lookup. However, it isn't. But you can call it repeatedly for all expected inputs, store those in your own lookup table and access that.

I'd recommend that Microsoft adds a lookDontTouch flag to the wFlags parameter; that would be a trivial non-breaking API fix.

Answer 2

If you broaden your search to include key logging, you might get some answers. The method presented in the link is extremely cumbersome compared to ToUnicode, but it works. It evolves around finding the current active keyboard layout from the registry and then manually load and parse the proper DLL.

As a note of warning, I've seen the loading part fail miserably on 64-bit Windows.