pete@titan.rice.edu (Pete Keleher) (11/29/89)
I'd like to be able to use the option key in an way analagous to the way that the command (clover,whatever) key is used. Unfortunately, the option key changes the character that the keyboard sends. This could be handled by using a table to map option chars back to the original chars, except that not all option sequences generate keyDown events. Specifically, the option-n sequence seems to want to combine with the next keyDown, so no event is generated, and the only way that I know to detect an option-n sequence is the 'getKeys' call, not a good solution. I think that I read in the Red Ryder 10.0 docs that someone wrote a new keyboard driver for him because previous versions of Red Ryder had had the same problem. Sleuthing with TMON showed that the previous versions had used the same kludgey solution that I had used. I would appreciate any information or ideas on how the driver is implemented or what it entails. Is IM sufficient? 'Preditor' also claims to be able to use the option key, but I don't know if it uses it correctly. Any information on how Preditor handles this (if correctly) would also be appreciated. -- =========================================================================== Pete Keleher pete@titan.rice.edu Rice University knows nuttin about what I say, or what I do ... ===========================================================================
amanda@intercon.com (Amanda Walker) (11/29/89)
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. Amanda Walker InterCon Systems Corporation amanda@intercon.com --
ml10+@andrew.cmu.edu (Michael A. Libes) (11/29/89)
>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
kazim@Apple.COM (Alex Kazim) (11/30/89)
In article <MZQqW_y00Uh7032nkB@andrew.cmu.edu> ml10+@andrew.cmu.edu (Michael A. Libes) writes: > >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 Uh, this is fine for a keydown event, but what about dead keys. I had thought, and this is off the top of my head, that option-e will not generate a keyDown event. If this is the case, then you won't be able to trap out the dead keys opt-e, opt-`, etc. Of course, I could be wrong... ======================================================================= Alex Kazim, Apple Computer On a dark desert highway... =======================================================================
amanda@intercon.com (Amanda Walker) (12/01/89)
In article <36863@apple.Apple.COM>, kazim@Apple.COM (Alex Kazim) writes: > Uh, this is fine for a keydown event, but what about dead keys. I had > thought, and this is off the top of my head, that option-e will not > generate a keyDown event. This is the problem, in fact. The reason we ended up doing a head patch on KeyTrans instead of using our own KCHR is that we have a lot of customers overseas, and we didn't want to end up making a duplicate of all of the international KCHRs. This way, also, we're automatically compatible with any new keyboard mappings that happen to come by. One other note to people who decide to try this technique: if you don't turn your patch on and off at MultiFinder suspend & resume events, your users will curse your name forever :-)... -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
amanda@intercon.com (Amanda Walker) (12/01/89)
In article <1587@intercon.com>, amanda@intercon.com (Amanda Walker) writes: > One other note to people who decide to try this technique: if you don't turn > your patch on and off at MultiFinder suspend & resume events, your users > will curse your name forever :-)... I goofed. I meant window activate & deactivate events (which you should be doing for MultiFinder anyway, but...). In particular, your users may well want to type option-characters at desk accessories. Take only pictures, leave only footprints, as they say. -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
t-jlee@microsoft.UUCP (Johnny Lee) (12/02/89)
In article <MZQqW_y00Uh7032nkB@andrew.cmu.edu> ml10+@andrew.cmu.edu (Michael A. Libes) writes: [Stuff Deleted about using custom KCHR resource or patching KeyTrans] > >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 The original posting concerned using the option key as the Control key on pre-ADB keyboards. With some option-key combinations, i.e. option-e or option-n, the system will not report the keyDown since this combination is a "dead-key". The next keydown generated by the user will determine what ASCII code is returned, i.e. in the case of option-e - if you press an e afterwards you'll get an e with an accent aigu(how do you spell it??) The method you describe above will work for the other modifier keys but not the option key. I tried the same thing for Mac Nethack and it doesn't work. My kluge was to force the user to type in option-shift-N instead. Really awful, but at the time I just wanted it to work. So no, Amanda's method's aren't too much effort if you want the option key to behave like the other modifier keys. It's just the right amount. Though I wish there were another way of doing it. Something simple like setting a flag of some sort. Johnny Lee t-jlee@microsoft.UUCP Standard Disclaimer
svc@well.UUCP (Leonard Rosenthol) (12/07/89)
In article <36863@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >In article <MZQqW_y00Uh7032nkB@andrew.cmu.edu> ml10+@andrew.cmu.edu (Michael A. Libes) writes: >> >>[possible solution using event message] > >Uh, this is fine for a keydown event, but what about dead keys. I had >thought, and this is off the top of my head, that option-e will not >generate a keyDown event. If this is the case, then you won't be able >to trap out the dead keys opt-e, opt-`, etc. Of course, I could be >wrong... > Nope, you are right on this one Alex! Dead keys will NOT generate keydowns ans so this won't help in this situation... The only way to support use of the optionKey as the controlKey (or any other type of modifier for that matter (meta-Key??) is to patch _KeyTrans! (You also have to do some other stuff behind the system's back since it is possible for you to get a keyDown event which was generated while your patch was switched out during a MINOR context switch...(Don't y ou just love MF ;-) -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025