c# - Create an On-screen Keyboard

Question

I use PostMessage to simulate keystrokes in a program that is in the background. It work fine except for characters that need shift on the physical keyboard. How do I simulate shift? "

The code I use is roughly:

 VK vk = VkKeyScanEx (c, GetKeyboardLayout (0));

 AttachThreadInput (_attachedThredId, _attachedProcessId, true);
 PostMessage       (_window, WM_KEYDOWN, vk.key, 0x1);
 PostMessage       (_window, WM_KEYUP,   vk.key, 0xC0010001);
 AttachThreadInput (_attachedThredId, _attachedProcessId, false);

How should I handle Extended part of VK?

Edit

I'm trying to create an on-screen keyboard. Each button on the on-screen keyboard simulates a sequence of keystrokes. The receiver is an old program that performs different tasks depending on the keyboard sequence that is performed. Keyboard sequences is as follows

• {ESC}NN{ESC}NN
• {ESC}NN
• ?NN
• §NN

where {ESC} simulate pressing the Esc key, NN are hex values and §/? get the program to listen.

Normally we have special physical keyboard to control the program, but they are expensive. So in a test environment where we do not always have the physical keyboards, we have to enter these codes manually

Answer 1

You must compromise:

If you want to simulate keyboard input, then you must use SendInput, which means being at the mercy of which window currently has focus. SendInput is like hitting the keys on your physical keyboard. The only way you can send your keystrokes to a specific window using your keyboard is to ALT+TAB to the right window.

If you want to send keystrokes to a specific window, then you incur funky behavior:

1. Applications handle input differently. And simple WM_KEYDOWN / WM_KEYUP messages are not the only way to detect keyboard input. For example there is also the keyboard state (GetKeyboardState()) which you will have a harder time simulating. This is most likely what you're experiencing.
2. Applications may RELY on the standard behavior of having focus while receiving keyboard input messages. By posting messages to these applications, you invoke strange out-of-order behavior that may crash them.
3. Now multiple windows on the system can be receiving keyboard input at the same time. This might also cause strange behavior.
4. (etc...) Hooks won't be called for this input, your keyboard / input drivers won't see it, it won't be recognized by things like DirectInput... basically it's a never-ending patchwork of issues by doing something the bad-bear way.

There is no way around those side-effects; it's the consequence of doing shady stuff.

---

A solution for your purposes, because you're targeting a single specific application, may be to use PostMessage in conjunction with SetKeyboardState to simulate the keyboard state including shift positions.