Simulating number-sign (#) keystroke in C#

Question

I'm trying to accurately type a hash sign (number sign, pound sign, octothorpe, whatever you call it) using SendInput in user32.dll.

These are the possible options I see:

1. Type the number-sign by simulating SHIFT+3 (SHFT_DN, 3_DN, 3_UP, SHFT_UP). My only concern would be US-layout keyboards. Is there a possibility of a system that is configured with non-US layouts to output an incorrect key?

2. My other option would be to insert the character by the ascii code by simulating key press: ALT+035 (ALT_DN, NUMPAD0_DN, NUMPAD0_UP, NUMPAD3_DN, NUMPAD3_UP, NUMPAD5_DN, NUMPAD5_UP, ALT_UP). Are there any major downfalls to this method? Do all regions share the same ASCII codes and does Windows provide this ALT+### functionality in all regions? This is also going to generate a lot of keystrokes for a single simple character. I don't know if that's a potential problem.

3. Ideally there would be a Virtual Key Code that was a hash symbol, but I don't see one. Am I missing it?

Any other possibilities that I'm not thinking of? I really need to continue using SendInput for a few reasons.

So my question is, how do I use SendInput to simulate a number/hash sign being typed, and make that be global and not-dependent on non-US keyboards with the least number of keystrokes possible?

Thank you

Answer 1

You should be able to do this using SendInput with the KEYEVENTF_UNICODE flag. This bypasses the problems discussed in the comments about different keyboards using different scan codes to represent the number sign. It has a universally recognized Unicode representation.

The KEYEVENTF_UNICODE flag should be specified in the dwFlags member of the KEYBDINPUT structure that you pass to the SendInput function. When you use this flag, you set the wVk member to 0 and use the wScan member instead. The documentation for that structure contains more detailed information.

But it should be pretty simple. Any properly-designed app is going to obtain the message (using either GetMessage or PeekMessage), and then call TranslateMessage, which will cause a WM_CHAR message to be posted with the appropriate Unicode character value. It even handles the case where you're dealing with a legacy, non-Unicode application: if the message is posted to an ANSI window, the Unicode value will be automatically converted to the appropriate ANSI value. This shouldn't be a problem, all character sets I can think of include a number sign.

Alternatively, you could probably do the translation yourself using the VkKeyScanEx function to obtain the virtual-key code of the character, and then mapping this virtual-key code to a scan code using MapVirtualKeyEx. I can't say for sure if this will work, though, as I've never tried this approach.