Closed Bug 12497 Opened 21 years ago Closed 21 years ago
Need policy on char codes for modifier keys
A recent checkin switched editor events from KeyDown to KeyPress events, and that means that now we're getting char codes instead of key codes. This is fine for everything except alt keys, for which the char codes are different on all platforms so there's no way to write XP code which recognizes them. The platforms can't write their event code because there's no spec for what they should be doing (which is why they're all different -- everybody had to guess and they all guessed a different way). The fundamental question which needs to be solved is: when a modifier key is down, should the char code reflect the lower case value of the key, or the upper case? And should it be different depending on whether the shift key is pressed? Personally, I would argue for making the char code follow the shift key, i.e. alt-a gives a char code of a, alt-shift-a gives a char code of A as well as having the shift modifier bit set; and that also, alt-2 gives a char code of 2, alt-shift-2 gives a char code of @ (assuming that's what's above the 2 on the keyboard being used). But whether or not you choose to follow that recommendation, the important thing is that we need a policy one way or the other so that we can make alt key events work again.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
In the absence of a policy, I have chosen one (with Kathy and Shaver's agreement, and after checking with hyatt and saari), which is the one already outlined in this bug; and I have checked in the changes to the gtk event handler, and a minor change for the alt-x case to the editor hardwired bindings. I've filed bugs against Mac and NT to fix their char code generation accordingly.
Well I agree with the policy. I'll have to figure out the correct implementation on Windows. Currently on Windows at least we get a translated character based on the key hit but only when hitting Ascii characters. When hitting non-Ascii characters no WM_CHAR event (the Windows event we key Keypress event off of) is generated. This could be tough to do.
Mass update: changing qacontact to email@example.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
VERIFIED ON BUILD 2001-07-30-08-TRUNK
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.