Re: This time a real clip bug: it crashes...

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Bob Zimmerman  on Tue, 28 Feb 2006
19:36:44 -0500

Bob:

> As for the CLIP crash bug, Robert Holmgren had noticed that the
> End-of-File charactor (EOF) was in the text of the messages I
> had been sending, making him
> think that was the cause of the crashes.

I never thought (or said) that. I asked you where it came from, since XyWrite
excludes it. What it meant to me is that extraneous characters are coming from
*somewhere*, and that that "somewhere" might be the source of Clip's crash.
You subsequently identified an intermediate app that you use to process your
email texts. As for the EOF char itself, I specifically said that the
Clipboard would not be troubled by it. Clip.Exe only pays attention to it (and
excludes it), if it is the very last character in the clip; but if it occurs
somewhere in the middle, Clip lets it pass. XyWrite, however, would terminate
reading of any clip when it encountered any instance of that character. So, by
definition, if you are only using Clip to Copy, and never to Paste (as you
say), and if Default 1A=0 (as it does), then char 26 cannot be the cause.

But wait! On second thought... you said "When I clip from Windows to Xy4 I use
the standard Windows commands instead of CLIP." And elsewhere you said "I use
a macro program called QM. When I want to reply to an email, it is this program
that creates a reply email, selects the quoted text, dumps it into the
clipboard, opens Xy4, and then clips the text into Xy4." So in other words,
you're running XyWrite in a Desktop Window, and you're using either Windows
standard services or QM to put the Clipboard text into XyWrite's window! That
_could_ easily put an illegal character into XyWrite.

> However, I now think that this
> character might be irrelevant to the problem.

My guess is, Win98 is choking on Unicode. The only illegal Clipboard char is
Ascii-0 -- it brings the whole Clipboard to a dead stop.

> Robert's suggestion that I solve the CAPSLOCK bug by
> putting the Capslock key back to its standard position
> might work, but isn't this listserv made up of
> people who stick with Xywrite because they want to
> do things their way?

Sure. But they don't violate the hardware deliberately -- or if they do, they
don't bring it to our attention in the guise of a "bug" and ask why it happens!
What I wrote was this:

"Bob, however much you customize, one thing that I would most
certainly NOT do is mess with a hardware Locking key (CAPS, NUM, INSERT,
SCROLL) and reassign it to a key value that the hardware doesn't recognize.
The first thing I noticed (under NT) was that toggling key 101 (the CursorLeft
key) as your CapsLock is not recognized by the operating system in any way.
It's obvious that other running applications, and the OpSys itself, do not
recognize this toggle. You are in uncharted territory here, and I'm just
stunned that you are the least bit surprised by anomalous results -- or that
you even raise the issue before trying to change [CAPS, renamed to] CASS back
to key 58 where it belongs. I mean, have you tested the result with a
factory-issue KBD file??? Do you get the same freeze? That's just basic
debugging..."

Then you subsequently tested with a factory KBD file, and guess what -- problem
disappeared.

So my point is, your mileage is definitely varying. You have pros, and you
have cons, and you make a choice. But it isn't a "minor bug"! It's a willful
overriding of the hardware.

If I wanted to reassign CapsLock to LeftArrow (and I've been reassigning the
CapsLock for 15 years, without any problem whatsoever), I would remap the
keyboard **hardware** at a low level, using a remappable external keyboard, so
that LeftArrow is recognized as VK_CAPITAL (Virtual Key 14h) by all programs
and by the operating system; I would leave CAPS assigned to key 58 in XyWrite
(LeftArrow would now *be* key 58).

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