Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!widener!ukma!memstvx1!utkcs2!emory!wuarchive!usc!apple!apple.com!gandalf From: gandalf@apple.com (Martin Gannholm) Newsgroups: comp.sys.mac.programmer Subject: Re: character codes vs. key codes Message-ID: <13573@goofy.Apple.COM> Date: 20 May 91 23:54:41 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 91 References:<1074@sys.uea.ac.uk> In article 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.