john13@garfield.MUN.EDU (John Russell) (10/24/88)
One of the things I find myself doing more and more lately is feeding fake input events to the keyboard, eg in TSnip (used to be Snip) and CVI (adds mouse control to vi in a term program). I'm not sure exactly how upward compatible the method I'm using is, and I have no illusions about its working with different keymaps. Is there a CBM-blessed method for taking an ASCII character and determining the rawkey scancode(s) that are necessary to generate it? Note this is the _opposite_ of deadkeyconvert(). Ideally it should handle the entire printable ASCII set, including those requiring a deadkey first, and allowed combinations of qualifiers. John -- "The 68000 processor can't possibly handle a colour display. You must have a 68020 system and not know it." -- Amiga and Atari ST owners shared a chuckle over this view from sales *and* technical people at the local Apple dealer
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:Is there a CBM-blessed method for taking an ASCII character and determining :the rawkey scancode(s) that are necessary to generate it? Note this is :the _opposite_ of deadkeyconvert(). Ideally it should handle the entire :printable ASCII set, including those requiring a deadkey first, and :allowed combinations of qualifiers. : :John Look at KEYBOARD.C in the DME source just posted by the moderator to comp.sources.amiga ... DME does this kind of reverse engineering when it starts up so it can convert key specifications to raw codes for the MAP command. Essentially you just declare an InputEvent structure and stuff it, in turn, with all the keycodes, then send it through RawKeyConvert() to see what ascii, if any, turns up. There are some special cases, like multiple codes mapping to the same ascii char, but all in all it's relatively painless. The other way to do it, especially if you want to be fancy and figure out multiple-key sequences, it to obtain the keymap and scan that. -Matt