From:	ovek AT arcticnet DOT no (Ove Kaaven)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Allegro & shift keys
Date:	Mon, 03 Mar 1997 09:10:09 GMT
Organization:	Vplan Programvare AS
Lines:	28
Message-ID:	<5ffngk$ftl$1@troll.powertech.no>
References:	<3315CEEB DOT 133F AT search DOT van DOT wa DOT us> <kNVa0OA27zFzEwI8 AT talula DOT demon DOT co DOT uk> <5fep3a$sgr AT lyra DOT csx DOT cam DOT ac DOT uk>
NNTP-Posting-Host:	alwayscold.darkness.arcticnet.no
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

mejm2 AT hermes DOT cam DOT ac DOT uk (Michael Meeks) wrote:

>	A more interesting ( possibly ) question is : why does the K/B
>hardware react like this :

>	If <shift> is down, and then <arrow up> is pressed,
>		The interrupt handler receives :
>			<extended shift> off, <arrow up> down   ?

>	This really cocks up handlers that use the same map for extended
>and normal keys. ( By extended I mean a dual code thing 0xA0, code (
>perhaps ) ).

>	Is there any logical reason for this / is this a figment of my
>imagination ?

You might find the behaviour even stranger if Num Lock is active, it
would then generate <extended shift on> when shift is not down. This
only happens to the grey arrow keys, not the numpad keys. The reason
for this is that a simple keyboard handler would normally translate
Shift+numpad to generate the corresponding digit, instead of the arrow
key (and vice versa with NumLock on). The hardware will try to avoid
this for the grey arrow keys by using the extended shift sequence, to
simulate an unmodified arrow key.

By the way, I thought Allegro already intercepted extended shifts?

- Raw text -