In the meantime, I recommend #1 or #3 from the list above. I'm going to leave this open for about a week to see what people think. Recommend people use Microsoft PowerToys - which actively remaps combination keys and more - if Right Alt doesn't get them there.Update the FAQ to call out that AltGr is supported by remapping Right Alt in it's place.Remove AltGr from the list of supported key values and write to Registry code by reverting the change the brought it. I've looked at past pos1ts but im 1sti11l1l 1n1ot 100 sure, as you can tell m1y 1111111 key is having an issue since I foolishly spilt water on it and pondering my ways to disable the key I found sharpkey, I'm not sure if this is the right place to ask or if it's sti1l1l 111acti1v1e 1but1 1i1m still gonna ask.I believe that my solution to this is a three-part fix:
And since it's a triple-byte code, it's not getting the information correctly, which causes an the UX to display the wrong key. The problem here is that there code that reads back in the Registry value was never updated to expect the triple-byte value: only the code that writes out to the value does. The addition of AltGr came from a GitHub user and at the time, I called out that as a triple-byte coded key, it was not going to be something that SharpKeys could support because the underlying Windows technology - the Scancode key in the Registry - doesn't support it, What I think the contributing coder found was that if you use the Right Alt key, the Registry can leverage that scancode and use it to remap AltGr, since the first half of the key is the same code, meaning that if you write out the triple-byte AltGr key, they Registry sees enough of Right Alt and remaps it successfully
0 kommentar(er)
