https://bugs.winehq.org/show_bug.cgi?id=36854
--- Comment #26 from Karol Herbst wine@karolherbst.de --- (In reply to Ken Thomases from comment #25)
(In reply to Karol Herbst from comment #24)
currently I try to understand the ToUnicodeEx function a bit more:
example ^^: IN ^ OUT -1 "^" IN ^ OUT 1 "^" (though windows prints ^^)
example ^a: IN ^ OUT -1 "^" IN a OUT 1 "â"
example ^p: IN ^ OUT -1 "^" IN p OUT 2 "^p"
I'm not entirely sure what the above means. In particular, the input to ToUnicodeEx() is a keystroke along with the key state, but you show a character.
yeah, I know. I just meant the virtual keys, which are translated to the characters.
I have some questions here:
- should the first call produce a "^" translation? If not, are there
special characters, which should be used for X11?
I'm not sure what you're asking. First, nothing X11-specific should be returned to the caller of ToUnicodeEx(). It's a Win32 function, so the behavior should be as close as possible to the behavior on Windows (except that the user's keyboard layout may differ on the two platforms).
When ToUnicodeEx() returns -1, it indicates that the key was a dead key. The buffer should contain the (non-dead) character which corresponds to the dead key. For example, the app may display that character (perhaps with a special color or style) to indicate the pending dead-key state.
I see.
- should in the ^p example the second call return "^p", if the first
question answer is yes?
I believe so, yes. The first keystroke was a dead key. The second keystroke does not combine meaningfully with that dead key. So, the dead key becomes just a normal character. Plus the second keystroke produces a normal character. So, the call returns both characters.
In the first version I would only care about the first example and use the third one also for ^a (this can be changed later I guess).
I didn't understand this.
I meant, that I will ignore the "â" case and just put "^a" into the out buffer for now. If this works I will add support for the "â" case.