I'll try this and let you know what happens, Martin.

Thanks and 73 from Tom Behler: KB8TYJ

----- Original Message ----- 
From: "Martin McCormick" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, October 11, 2011 11:18 AM
Subject: Re: FW: Preliminary Observations of N3FJP's NAQP Logger with 
Various Screen Readers.


> This is almost certainly a contingency or conflict issue. You
> get them when two or more processes are trying to grab the same
> resource. I am speaking in general terms because I do not have
> the slightest idea whether we are dealing with a keyboard
> interrupt or what but that's what a contingency issue looks or
> sounds like.
>
> The screen readers for Windows probably install a full
> keyboard handler routine to make all the keyboard commands for
> the screen reader work and then what's left over gets passed on
> to the rest of the system for normal use. I would imagine that
> mouse movements get simulated and stuffed in somewhere and a lot
> of cool stuff happens behind the scenes to make the rest of your
> system feel like you have a mouse and are a normal Windows user
> even though you are running JAWS or NVBA or Window-eyes. It
> almost has to be that way to work at all.
> Since screen readers in Windows and DOS have to monkey with the
> system at a very low level, other software can easily step all
> over what the screen reader had to do and change the order of
> events or reset address vectors that the screen reader needed to
> work a certain way and that's how we get some of the weirdness
> such as the eaten first character that gets echoed but never
> stored.
>
> One interesting experiment you might try is to strike a
> key that normally does nothing by itself such as shift or Alt
> and then release it before you type that first character and see
> if that changes anything. If it makes it work, good. If not,
> back to the drawing board.
>
> Martin
>