CG>  NA> Sometimes this will lock up the keyboard, or not report anything in
CG>  NA> K$. For some reason, I've always had to do K$=INKEY$:K$=UCASE$(K$) 
o
CG>  NA> do any kind of keyboard reading. Any ideas why?
CG> 
CG> Howdy Nick,
CG> 
CG> I believe it's an old CP/M bug if you POKE that particular address more 
tha
CG> once.  Similar will happen with Num Lock.  PEEK and POKE should be used 
as 
CG> last resort, since one of these days MicroSoft just might try 
experimenting
CG> with the guts of MS-DOS.  Stay with the standard interrupts is much as 
you 
CG> if you need something beyond QuickBasic's direct control.
Hi Chris, didn't know you posted in here... ;). Yes, it looks like bug in 
OS.
I'm running OS/2, and I no longer have keyboard problems, since OS/2 traps 
and virtualises the keyboard (seems to prevent problems with apps that change
the keyboard rate or LED status). In DOS, I had no problems Peeking, just 
poking. Microsoft's way of saying "We don't like you poking around in low 
memory!" :)
CG> If you want your program to run under Windows gracefully, there are 
already
CG> some QuickBasic statements like ON KEY that can get you into trouble.
I've played around with ON TIMER to make a QB app give up a timeslice under 
OS/2, but it doesn't seem to affect anything, other than delay OS/2's 
switching from full screen to window. Any ideas on giving timeslices?
It could be worse, just imagine all the Windows problems I could do with 
at!
:)
Nick.
--- Renegade v5-11 Exp
---------------