Is there an "official" way to get a string representation of the key?

[DaltonSW]

I am trying to have a comma-delimited string representation of all of the keys a user has pressed over a given period of time (Ex: An 'add keys to list' screen that updates a label with the running list). I have tried using the RawKeyChar and KeyChar properties exposed by the KeyboardEventData class, but neither of them work for keys whose char isn't the language-representation of the key. I peeked through the code a bit, and couldn't find any translation functions either.

Just wanted to get some input before I end up just writing some sort of "KeyCode -> String representation" hardcoded dictionary/class

[DaltonSW]

While I am still interested in the answer to this, I did end up just writing my own translation util class for my program. Happy to fork and PR that, if you'd find it helpful :)

[TolikPylypchuk]

Hello! Thanks for asking!

As far as I understand, KeyChar of the KeyTyped event doesn't really suit you, because you don't want a character that's typed by the key press. Rather, you want the actual name of the key (i.e. what the key looks like on a physical keyboard). Unfortunately, there's no "official" way to get such a string representation of a key.

This is a problem which seems simple but may include some subtle edge cases. For example, the same key can have different names on different OSes: Alt on Windows is Option on macOS; Win key on Windows is Command on macOS, Super on some Linux distributions, and Meta on others; and for some absolutely inexplicable reason Microsoft recently announced a new Copilot key which, as far as I understand, is just a redesigned Win key, or maybe not, I'm not really sure. Also, the same key may have different meanings depending on the keyboard state, e.g. if the Function key is pressed or not.

I think writing some kind of a dictionary which maps keys to names depending on the OS is good enough while not being technically 100% correct for all possible cases.

Also, I don't think this feature should be included in SharpHook itself. As I've said it's too difficult to write a general-enough solution which works for vastly different users and use cases, and then maintain it. You should instead implement the mapping which works for you and not think about some arcane keyboard peculiarities. I'm really glad that you offered to provide such a feature, this is really appreciated! If you'd like, you can share a snippet or a gist with the mappings - this may be helpful for other users which would like to have something similar.

[DaltonSW]

That all makes a lot of sense. I actually ran into the "Windows vs Mac" as soon as I got to Backspace, so I totally get where you're coming from (don't even get me started on the Copilot key.......). Also totally reasonable to want to keep it separate from your core functionality.

A Gist is a great idea! https://gist.github.com/DaltonSW/d41e2fa527ce79581ea076893f16325e

Thanks for the reply, and thanks for making a great framework! It was such a blessing to find your Reddit post about this.

[TolikPylypchuk]

I've looked through the mappings and have a couple remarks if you don't mind. As I can see from the description, this is Windows-oriented.

• VcUnderscore is not really un underscore key, and it will not show up on Windows. It shows up only on macOS and is mapped to its kVK_JIS_Underscore key code.
• VcChangeInputSource is only available on macOS and is the key code of the Function key when it's used to change the keyboard layout.
• VcLeftMeta and VcRightMeta should be called Left Windows key and Right Windows key or something like that on Windows.
• VcKatakanaHiragana, VcKatakana and VcHiragana are only available on Linux so they're not going to show up on Windows.
• I'd map VcAccept to IME accept, VcConvert to IME convert, VcNonConvert to IME non-convert, VcModeChange to IME mode change, and VcProcess to IME process as they are related to the IME.

You can find the key code mappings in the docs.

[DaltonSW]

Thanks so much for these suggestions! I'm definitely fairly ignorant in the realm of broad I/O, so that's all really useful. I've implemented those.

I would eventually like to expand this to Mac and Linux support as well. Are there any other notable ones like you've mentioned that I should take care to factor in there?

[TolikPylypchuk]

Well, I think you can base the names of the keys on the key code mappings I've linked in the previous comment. For example, you can see there that VcRightMeta maps to kVK_RightCommand on macOS so you can infer that this is the right Command key. On Linux the Win keys are usually called Super or Meta (that's why the key codes in SharpHook are called VcLeftMeta and VcRightMeta). Other than that, nothing special really.

Also, I'm not really proficient in IME and its specifics. That point was based on the key code mappings as well.