utoddl@ecsvax.UUCP (Todd M. Lewis) (03/03/89)
[I posted this before but didn't see it show up, soooo....] Hello Net, I'm trying to set up something like what Matt does in DME so that I can map functions to keystrokes. But I don't want to make any assumptions about scancodes. DME assumes certain scan codes come from the keypad, but the keyboard grows every couple of years and I don't want my programs to get old and die. My question(s): Is there any way a program can predict (that is, compute on the fly rather than by table look-up) which scan codes will come from the keypad and which ones come from the main keyboard? I know that char codes from RawKeyConvert() for keypad scan codes stay the same regardless of IEQUALIFIERs, but that (I think) depends on the keymap in use at the time. I understand that RAWKEY events have a KEYMAP bit, but that doesn't help me predict which codes will come in that way. You see, I want to build these tables at program-initialization time -- before any messages get processed. The only thing I've been able to come up with is to have 2 identical tables, one for the keypad and one for the rest of the keyboard. When an event comes in, check the KEYMAP bit and use the approprate table. This means lots of unused table entries. (It's also easier to code, but it isn't clean enough for my sense of aesthetics.) Thanks, --Todd M. Lewis (This disclaimer is my employers idea -- The rest are mine.)
kodiak@amiga.UUCP (Robert R. Burns) (03/07/89)
In article <6597@ecsvax.UUCP> utoddl@ecsvax.UUCP (Todd M. Lewis) writes: )[I posted this before but didn't see it show up, soooo....] I saw it before, there was just no reply ) My question(s): Is there any way a program can predict (that is, )compute on the fly rather than by table look-up) which scan codes )will come from the keypad and which ones come from the main keyboard? No. )I understand that RAWKEY events have a KEYMAP bit, Actually, the keys on the numeric pad new for the 500/2000, i.e. ()/*+ don't even have this NUMERICPAD bit set. (They will for 1.4, but that's a small consolation) Solution: hard code it (shudder!). -- Bob Burns, amiga!kodiak "five year . _ | /_ _|. _ | Commodore __ service _/ \_ |_) _ |_ _ )' |<(_)(_)|(_\|< /\ | ||| _` /\ pin" `.(5).' |_)(_\| )(_\ | | \ Software ___/..\|\/|||__|/..\___ /.^.\ Faith
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (03/07/89)
In article <107@amiga.UUCP> kodiak@tooter.UUCP (Robert R. Burns) writes:
:Actually, the keys on the numeric pad new for the 500/2000, i.e. ()/*+
:don't even have this NUMERICPAD bit set. (They will for 1.4, but that's
:a small consolation)
:
:Solution: hard code it (shudder!).
Has *no one* produced a keymap for the 2000 that has the NUMERICPAD bit
set?
I don't mean to rattle C-A's cage but you talk about unsupported
programming practices! And forced on us by C-A, no less! Ah well, at
least I don't have to program a segmented architecture machine.
:--
:Bob Burns, amiga!kodiak
--
Tony Sumrall acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]kodiak@amiga.UUCP (Robert R. Burns) (03/10/89)
In article ... (Tony Sumrall) writes: >Has *no one* produced a keymap for the 2000 that has the NUMERICPAD bit set [for the new 500/2000 numeric pad keys]? Nope. The NUMERICPAD bit is set by the keyboard.device in rom, not by the keymap. The (1000) 1.2 keyboard code was not rolled for the new keyboard on the 500/2000. Neither was it for the "autoboot only" 1.3 release. That's why you've got a SetMap command in your startup sequence: to replace the rom keymap that doesn't know about the new numeric pad keys. -- Bob Burns, amiga!kodiak "five year . _ | /_ _|. _ | Commodore __ service _/ \_ |_) _ |_ _ )' |<(_)(_)|(_\|< /\ | ||| _` /\ pin" `.(5).' |_)(_\| )(_\ | | \ Software ___/..\|\/|||__|/..\___ /.^.\ Faith