SendInput the problem of analog keyboard input

Recently contacted with this function, so I learned a bit, and summed up the list here.

I understand how it starts by typing characters into the active window, which is a feature of many programs (I guess visual Assist x uses this feature).

According to MSDN, this function simulates keystrokes, inserts some messages into the input stream of the keyboard or mouse, Windows processes it, generates corresponding WM_KEYDOWN or Wm_keyup events, and enters the application's message loop along with the normal keyboard input. Not only can they be converted to WM_CHAR messages, they can also be converted to other messages, such as accelerator keys.

Use it to send character messages, and it doesn't look that simple. Here are two questions to consider:

1. Conversion of IME. For example, if you want to send some English characters to the active window, we might imagine this: get the virtual key for the corresponding keyboard character and send a sendinput. But if the active window is using an input method, then the message we send out will go into the input Method's composition window and eventually be converted to hieroglyphs or discarded. Only when the input method is turned off does the program run to show the English characters in the active window as we would expect.

2. What should I send to the active window for Chinese characters? Since the SendInput simulation is the Wm_keydown and Wm_keyup events, according to the general idea, should we get the Chinese character Input method encoding (pinyin or Wubi code), and then send the encoding related sendinput to the active window? That not only requires the active window to open the input method, but also to know how it is encoded.

As mentioned above, if you use SendInput to enter characters directly as you would imagine, you must analyze the IME state of the active window. and input in English, asked to close the input method, input Chinese, but also asked to open input method. If it is to be realized in such a way, it must be difficult to succeed.

So, is there a way to not rely on the active window IME state?

In fact, when using SendInput to simulate keyboard input, its parameters are keybdinput structure, by setting its dwflags member to Keyeventf_unicode. In this way, you only need to set Keybdinput.wscan to the Unicode encoding of the characters. For English characters, you do not need to close the input method of the active window, and for Chinese characters, the active window is not required to open IME and convert characters to IME encoding.

MSDN's description of this approach is that Input_keyboard supports non-keyboard input methods, such as handwriting recognition or speech recognition, which are indistinguishable with keyboard (text) input through Keyeventf_unicode identification. If you specify keyeventf_unicode,sendinput to send a wm_keydown or WM_KEYUP message to the active window's thread message queue, the message's wparam parameter is vk_packet. GetMessage or peedmessage Once this message is obtained, it is passed to Translatemessage,translatemessage to produce a WM_CHAR message based on the Unicode characters specified in the Wscan. If the window is an ANSI window, the Unicode characters are automatically converted to the corresponding ANSI characters.

Any feature that needs to enter characters into the active window, including English, should be implemented this way. In fact, the process of translating a keyboard message into a character message is complex, possibly related to many factors such as keyboard layout, area, shift status, and so on, which is why Windows uses TranslateMessage to transform messages. Therefore, you should not attempt to enter specific characters into the active window by keystroke events.

After testing, SendInput also has two noteworthy areas:

1. When the Keyeventf_keyup identity is not specified for keybdinput.dwflags, SendInput generates a WM_KEYDOWN message, otherwise a WM_KEYUP message is generated, because only Wm_keydown is converted to a character message, so If you target an input character, you should not specify a keyeventf_keyup identity.

2. If we want to achieve the effect of actually doing a keystroke: the order produces a wm_keydown and a Wm_keyup event. You must perform a sendinput operation in a manner that does not specify Keyeventf_keyup and specifies Keyeventf_keyup, respectively. SendInput allows multiple impersonation messages to be sent in a single call:

INPUT input[2];
memset (input, 0, 2 * sizeof (input));

Input[0].type = Input_keyboard;
INPUT[0].KI.WVK = data;

Input[1].type = Input_keyboard;
INPUT[1].KI.WVK = data;
Input[1].ki.dwflags = Keyeventf_keyup;

SendInput (2, input, sizeof (input));

But in practice, this will cause no messages to be generated. These two messages must be sent separately, as follows:

INPUT input[2];
memset (input, 0, 2 * sizeof (input));

Input[0].type = Input_keyboard;
INPUT[0].KI.WVK = data;
SendInput (1, input, sizeof (input));

Input[1].type = Input_keyboard;
INPUT[1].KI.WVK = data;
Input[1].ki.dwflags = Keyeventf_keyup;

SendInput (1, input + 1, sizeof (input));

I have a lot of questions about the 2nd content. Because the code that someone posted on the Internet was sent by merge, someone must have done it and succeeded. I am not sure whether it is related to the system or other factors. I tried to try to solve the problem, but I didn't succeed:

1. According to Msdn,keybdinput.time is a timestamp, if zero, the system will use its own timestamp. So I suspect that the two events that were sent together were ignored because their timestamps were the same. So I explicitly set this property in the preceding code, and then merge the send, and the result is still no message generated.

2. I have tried two cases: merge sent two messages do not specify Keyeventf_keyup (expect to get two identical character input); the two messages sent by the merge have different virtual key codes and none are specified keyeventf_ KEYUP (expect to get two different character inputs). The result still fails and no message is generated.

I don't know if this means: for keyboard input, the message merge is not allowed to be sent.

If you know the reason or test to different phenomena, please contact me:[email protected]

Related knowledge:

1. Input method can also handle the Unicode message sent by SendInput, the method is unknown. See the Immgetproperty method reference in MSDN: when the dwindex parameter is Igp_property, Ime_prop_accept_wide_vkey is a possible return value, It indicates that the IME handles the SendInput function to vk_packet the Unicode characters injected, and if the return value does not have that identity, the Unicode character is sent directly to the application.

SendInput the problem of analog keyboard input