ToAscii verändert Zustand der Tastatur

[smallsmoker]

Habe die Frage nun auch HIER gestellt (CROSSPOST)

darum geht es nicht ...

es ist ein bekanntes problem das ToAscii sowie ToUnicode den Tastatur-Buffer löschen.

Das hat nichts damit zu tuhen das der KeyboardState nicht genau von dem zeitpunkt stammt.

Ich habe ewig im internet recherchiert und wirklich viele haben dieses problem !

Beispiele:

ToAscii/ToUnicode in a keyboard hook destroys dead keys.

oder von der Seite die ich gepostet habe:

Zitat:

ToUnicode() does not only provide no support for dead keys, it also interferes with them to the point of not being able to type accented letters anymore. [...] Unless Microsoft reworks its implementation of ToUnicode(), we have to make our own improved version. This is going to be way longer than calling ToUnicode().

oder:

Using ToAscii inside keyboard hook modifies the keyboard result

oder:

Zitat:

NOTE: One could also use ToAscii() or ToUnicode() functions of the WindowsAPI to convert the keystrokes into text. However, these functions often behave in a strange manner (such as with accentuation and shift state)[...]

von hier

Eine lösung wäre vieleicht den buffer irgendwie wiederherzustellen ... kp wie das gehen sollte, ich hab da nich so tolle ideen deswegen hab ich ja hier gefragt.

edit: Habe den Code im ersten Post nicht gestest aber man kann das hier in Shaman's Keylogger beobachten

edit2: ich habe auch das hier gelesen verstehe es leider nicht ganz ...:

Zitat:

The parameters supplied to the ToAscii function might not be sufficient to translate the virtual-key code, because a previous dead key is stored in the keyboard layout.

aus msdn

edit3: Habe was (meiner meinung nach) interessantes gefunden:

Code:

George,

The problem probably lies with ToAsciiEx.
It takes keystrokes and converts it to (ascii) character codes.

When using ToAsciiEx in a global hook proc, this messes up the handling of dead key characters in the application that is being hooked ..
The reason is that ToAsciiEx stores (remembers) the dead key when pressed and does not return a character.
When a 2nd key is pressed, ToAsciiEx takes the stored dead key, combines that with the new key and returns the combined character.
If a hook proc calls ToAsciiEx, the hooked application will also call ToAsciiEx (Actually TranslateMessage does this in the applications main message loop). 
The fact that ToAsciiEx is called twice to process the same keystrokes messes up the dead key character combination, because the first ToAsciiEx that is called will eat the dead key that was stored and the 2nd ToAsciiEx will no longer find a dead key character stored and will therefore produce an incorrect ascii character ... 
We basically confuse ToAsciiEx by calling it twice to process the same keystrokes: once in the global hook and once in the hooked application .
Ofcourse, in English, these special characters like "à" do not exist and this problem does not occur there. But in most European languages it does.
I have found a number of attempts on the internet to work around this problem, but none of them works as it should.

A method that works is to simply trap the WM_CHAR message in a global hook.
A WM_CHAR message carries complete characters like é, ñ, etc.
A WM_CHAR message is generated by the API function TranslateMessage that takes the keystrokes (WM_KEYDOWN etc.)
and translates the virtual key codes into an ascii character (most likely by calling ToAsciiEx internally).
TranslateMessage is called in an applications main message loop like this:
Code:
    DO WHILE GetMessage(Msg, %NULL, 0, 0)
        TranslateMessage Msg
        DispatchMessage Msg
    LOOP
Strangely enough, I have read that there are applications that do NOT call TranslateMessage, and use a message loop like:
Code:
    DO WHILE GetMessage(Msg, %NULL, 0, 0)
        DispatchMessage Msg
    LOOP
Like this, no WM_CHAR messages are generated and a global hook can not trap the characters ...
However, keystroke messages like WM_KEYDOWN are still generated ..
I read that Borland Delphi shows (or showed) this behaviour, though I myself have never encountered a program behaving like this.
Apart from one I wrote myself to test.

Hope this helps (a bit)...

Kind regards

(Hab das male in [ Code ] gepackt weils soviel is)

Kommt von hier