Re: U2-two minor bugs...

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Bob Zimmerman  on Mon, 20 Feb 2006
14:48:40 -0500

Bob, the Win9x series are very ill-behaved and primitive OpSyses (unlike either
DOS or NT). Apart from the questions of why, in the first instance, you are in
CapsLock mode at startup, and why XyWrite locks up, you've also bumped into one
of the toughest nuts to crack, namely programmatic manipulation of the locking
keys under 9x. When you toggle the locking keys (Caps/Num/Scroll/Insert) in 9x
using virtual keys, as both CAPSLOCK.EXE and GoXy do, you get very flaky
results. Sometimes the locking keys don't respond at all. At best, the toggle
only affects the current program, NOT(!) including COMMAND.COM itself. You can
prove this with the following command, at a DOS prompt:
 GoXy "{self}" /key(CI)x  [CI turns CapsLock ON]
That puts an UPPERcase X on the next line. Whereas:
 GoXy "{self}" /key(CO)x  [CO turns CapsLock OFF]
puts a lowercase x on the next line.
But in both cases, the *system state* of the Locking key is unaffected. If you
manually type more characters, they reflect the old system state. The new
state of the key would have persisted as long as GoXy was running, but when
GoXy quits, the original state of the key is restored.

So, in theory anyway, the solution might be to poke a virtual CapsLock toggle
into XyWrite itself, after it is running. You would have to accomplish that
from STARTUP.INT, not from the BATch file that launches Editor. This approach
should work, but given how creaky 9x is, how pathetically slow to respond at
the API level (Win98 being marginally more responsive than Win95), you might
not get reliable behavior. Note that XyWrite itself has the same problems:
the XyWrite functions that control the Caps and Num Locks scarcely ever work.
That's also why XyWrite's understanding of the CapsLock state is frequently out
of sync with the system state (one is locked, the other isn't, or v.v.). The
only thing that reliably works is a physical keystroke.

The real question here is what is going on with your system freeze. Have you
debugged this behavior yet? I can't tell from your msg. For example, if you
disable STARTUP.INT (REName it), is the system frozen or not? There's no sense
fretting about your various files if they're not even loaded yet (your
INiTialization file isn't read) and XyWrite is already frozen! But if it isn't
frozen, then work your way through STARTUP.INT until it freezes... (put 
after each line, and work downward). Where exactly does it freeze? And so
forth.

You say "I can unlock it by pressing CTRL-SHIFT-ALT simultaneously a number of
times". I don't get it. If "the program locks", which I interpret to mean
that XyWrite is *frozen* and unresponsive, then why is XyWrite responding to
CTRL-SHIFT-ALT? And what assigned in the KBD file to CTRL-SHIFT-ALT? I got
nuthin assigned to CTRL-SHIFT-ALT, so that is not exactly useful information.
The underlying assignment would be useful information -- or maybe I'm not
reading you closely enough...

Anyway, NT is extremely well-behaved, and does exactly what you tell it to do
(Locking keys and the whole nine yards). Plus NT has all sorts of
sophisticated protections in this viral era, which 9x never contemplated and
which make 9x ever more dangerous to use as your workhorse machine -- a pain to
use and a real PITA to support.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------