Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!ml10+ From: ml10+@andrew.cmu.edu (Michael A. Libes) Newsgroups: comp.sys.mac.programmer Subject: Re: Option Key and the Keyboard Driver, Red Ryder Message-ID: Date: 29 Nov 89 05:26:34 GMT References: , <1578@intercon.com> Organization: Class of '91, Carnegie Mellon, Pittsburgh, PA Lines: 24 In-Reply-To: <1578@intercon.com> >There are two approaches you can take. The first is to create a custom KCHR >resource. KCHR resources determine the mappings between keystrokes (including >modifier keys and 'dead key' sequences) and the codes that are reported in >keyDown events. You can tell the system to use your nifty new KCHR by using >the Script Manager call "KeyScript" (see IM V for more information). >The other approach is dirtier but simpler for some applications. The idea >is that you do a head patch on the "KeyTrans" trap, which is what takes >keystrokes and maps them by means of the currently active KCHR. KeyTrans >gets the virtual keycode and the current state of the modifier keys as >arguments. We use this to pretend the Option key is a Control key on non-ADB >keyboards, for example, by swapping the values of the Control and Option >bits. Once again, IM V should cover this. These are probably a bit too much effort for your need. When you get a keyDown or autoKey event, the message field of the event contains two integers. The loword of the message is the extended ascii value of the key and this is modified by option. The hiword, however is the keycode of the pressed key and the modifiers field contains all the modifiers which were pressed at the time of the event. The keycodes for all the keyboards are in IM I & V. You might have to do some parsing, e.g. checking if the shift key was pressed, but this method is quite simple. -luni