🚀 go-pugleaf

SORROW%oak.decnet@pine.circa.ufl.edu writes:
>Could someone tell me what the sticky keyboard problem is?  I have
>a Northgate OmniKey keyboard which supports sticky keys normally,
>but I have this feature disabled....since using 3.0 of BC++ thought
>the shift or ctrl keys occasionally get "stuck" in BC++...but I thought
>it was a problem with my kbd...is this the problem?

The problem you are seeing is what I am calling the "sticky keyboard
problem". I received a truly wonderful thorough analysis of the
problem from creasey@oz.dg.com who conducted timing tests of keyboards
and interrupt service routines to track down similar problems with
other software.

Jack, if you're reading this, mail to you bounced badly, but thank you
and I would like a copy of your timing software.

As a result of his analysis, I hope to have the problem cleared up
completely in the update to BC++ 3.0 that we are releasing to support
Windows 3.1, if it isn't too late to get it in there and tested.

The blame can't be laid only on the keyboard, keyboard BIOS, memory
managers, BC++, device drivers or TSR's that hook INT 9, but any or
all of them can be a factor. The basic problem is that an extended
keyboard non-numeric pad cursor key can send up to four scan codes
spaced 2 milliseconds apart from one keystroke, and the way most TSRs
and device drivers that hook INT 9 work, it's easy to end up losing a
keystroke and putting the keyboard BIOS out of synch. Since the BC++
IDE runs in protected mode and switches to real mode on every keyboard
interrupt, it adds the mode-switching time on top of everything else,
which may be enough to lead to symptoms where none were before.

Now that I have the details what is happening, I have something to try
that I hope will prevent the problem while BC++ is running if it isn't
ocurring without BC++.

 -- sidney markowitz <sidney@borland.com>