jrk@sys.uea.ac.uk (Richard Kennaway) (05/16/91)
When should one use key codes, and when character codes, to determine which key was typed? IM 1 says that one should normally use character codes, not keycodes, but sometimes one has no alternative but to use keycodes. For example, on the Extended Keyboard, the function keys F1-F15 all generate the same character code, and can only be distinguished by their keycodes. In some cases, the answer is fairly clear. For determining whether a key event is a visible character, to be inserted into a piece of text, one should use the character code. The character codes for return and control-M are the same, as are those for enter and control-C, so those must be detected by key codes (unless you're writing a terminal emulator - outside that context, the relation between control-M and return is of only historical significance). Identifying F1-F15 requires the key code. Distinguishing keypad characters from main keyboard characters requires key codes. What should one do in the case of arrow keys? The escape key? (The latter is probably ambiguous with control-[, but I havent tested this.) The problem with using key codes is that the relation between key codes and character codes may vary from one keyboard to another. According to the latest version of TN 160, an extra level of code mapping has recently been introduced between the physical keystroke and the event record, adding a further source of uncertainty about what the key codes and character codes that my program sees really mean. I can't experiment with all the different keyboards and Systems that exist. Are there general rules which will work in all cases? I'm not wanting to do anything low-level or complicated, like using the keyboard to control a video game, just a simple text editor that correctly handles every possible key event on all Macs, all keyboards, and all Systems. Is this possible? -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcsun!ukc!uea-sys!jrk
n67786@cc.tut.fi (Tero Nieminen) (05/17/91)
In article <1074@sys.uea.ac.uk> jrk@sys.uea.ac.uk (Richard Kennaway) writes:
When should one use key codes, and when character codes, to determine
which key was typed?
IM 1 says that one should normally use character codes, not keycodes,
but sometimes one has no alternative but to use keycodes. For example,
on the Extended Keyboard, the function keys F1-F15 all generate the same
character code, and can only be distinguished by their keycodes.
I can't experiment with all the different keyboards and Systems that
exist. Are there general rules which will work in all cases? I'm not
wanting to do anything low-level or complicated, like using the keyboard
to control a video game, just a simple text editor that correctly handles
every possible key event on all Macs, all keyboards, and all Systems. Is
this possible?
Not to mention the trouble of trying to compose meaningfull keyboard
alternatives, like Cmd-S, Shift-Cmd-S and Option-Cmd-S. Thesse will be
scattered all over the keyboard depending on the particular country.
--
Tero Nieminen Tampere University of Technology
n67786@cc.tut.fi Tampere, Finland, Europegandalf@apple.com (Martin Gannholm) (05/21/91)
References:<1074@sys.uea.ac.uk> <N67786.91May17032924@lehtori.cc.tut.fi> In article <N67786.91May17032924@lehtori.cc.tut.fi> n67786@cc.tut.fi (Tero Nieminen) writes: > In article <1074@sys.uea.ac.uk> jrk@sys.uea.ac.uk (Richard Kennaway) writes: > > When should one use key codes, and when character codes, to determine > which key was typed? > > IM 1 says that one should normally use character codes, not keycodes, > but sometimes one has no alternative but to use keycodes. For example, > on the Extended Keyboard, the function keys F1-F15 all generate the same > character code, and can only be distinguished by their keycodes. > > I can't experiment with all the different keyboards and Systems that > exist. Are there general rules which will work in all cases? I'm not > wanting to do anything low-level or complicated, like using the keyboard > to control a video game, just a simple text editor that correctly handles > every possible key event on all Macs, all keyboards, and all Systems. Is > this possible? > > Not to mention the trouble of trying to compose meaningfull keyboard > alternatives, like Cmd-S, Shift-Cmd-S and Option-Cmd-S. Thesse will be > scattered all over the keyboard depending on the particular country. When it comes to most cases of handling keyboard input, the character code is the way to go. If you need to distinguish whether function keys are pressed, or some of the other special keys on the extended keyboard then referring to the keycode is the only way to go, and the keycodes for these special keys don't change between localized versions of the system. There is one weird case of arrow keys, and it has to do with the old 128K keyboard. It has a numeric keypad as an option, and you could generate arrow keys by holding down the shift key while pressing some of the operators on the numeric pad. As for other cmd-key and cmd-option parsing, there is a way to handle it very elegantly. (The default for these kinds of things is of course to just have the key in the menu, and let the menu manager take care of it. However, there are several problems with this, partly because the Menu Manager strips accents from the command key. The other problem is of course that option-characters occur in wildly different places on foreign keyboards. Especially the Swedish and Finnish keyboards, where almost the entire option-layout is different [I should know, since I created it! For good reason, too].) Anyhow, on to the perfect solution: First, find out what the "base" character of that key is, i.e. what the ascii code would have been if no modifier keys were held down. a) Get the current KCHR with the following snippet of code: kchrHandle := GetResource('KCHR',GetScript(smRoman,smScriptKeys)); b) Then call KeyTrans on the kchrHandle, event keyCode and a zero (no modifier keys) state. Then, pass the "base" character and the real modifier event field to a routine of yours that looks up in a table what effect that combination should have in your program. This has the benefit of working on all keyboards in all languages, provided you only use the characters on the keyboard that are in unshifted positions on all keyboards. This will basically only guarantee you a-z, tab, space, return, backspace. If you count on the numeric keypad, I guess you can add 0-9, =, /, *, -, + to that list (except of course for shifted operators on the original Mac keyboard). Isn't it great when you can tell your users that they should press cmd-option-p to get a certain feature, and have it work on any language system with any keyboard? Oh, by the way, in the above method description I left out a step that is needed to "Fix" the keycode returned if you have an International Original 128K keyboard. The key code is remapped by the keyboard driver before being passed through KeyTrans, but the keyCode field of the event record isn't updated with the remapped version. The contortions to fix this are too gross to go into here, so I won't. Final note: HyperCard 2.0 and beyond does all this just for the reasons outlined, and hopefully provides for a better, more international product. (Not just international, more and more people in the U.S. are using foreign language systems!). Martin Gannholm Apple Computer Exclaimer!!! I never said it...Nobody heard me say it...You can't prove anything! Disclaimer: The above are merely ramblings from the author's memory. The actual level of correctness may vary. Valid where not void, etc.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (05/21/91)
gandalf@apple.com (Martin Gannholm) writes: >Isn't it great when you can tell your users that they should press >cmd-option-p to get a certain feature, and have it work on any language >system with any keyboard? Not only that, but it allows option-command-p to be a variant of command-p, just like option-click is a variant of a normal click. I think this makes for a much better human interface; once you start putting diamonds, radicals, and integral signs in your menus, you have strayed from the narrow road... -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner