Re: WILD CARDS

[ROBERT HOLMGREN]

David, on further reflection, I realized that I could cut the
Capture-the-CMline routine down further (the tank was unnecessary, for one
thing; so was the looping parse of a string of Wildcards), plus address all the
other wierd situations (Ascii-255, and wildcard WC) that occur on the CMline,
to really capture everything possible ultra-fast. That routine (CMLINE.PM),
commented, is nclosed here. To test it, load it on an ordinary Save/Get
(LDPM CMLINE.PM,x), then type a CMline with reverse-video wildcards, the
Ctrl-Enter wildcard (i.e. Ascii-10 in .KBD), and/or 3-byte "{Ascii-255}xx"
strings such as Ascii-0, 8, 9, 10, 13, etc. -- then step back and hit your S/G
key! (Smoke, a shattered hard disk, god what a mess.)

But something really odd, that I can't explain, was happening with *all* these
CMline capture routines. Some quirk in default boot-up XyWrite just didn't
want to process an Ascii-0 as the separator character in an XS parse. Yet,
after awhile, the routines would start to work properly, and then continue to
work properly throughout the remainder of the session. Obviously, something
internal needed to be "set" or "initialized" to make the buggers work, because
there was nothing superficially wrong with my code. To abbreviate a long
story, after isolating what I was doing that was forcing the bloody thing to
work, I found that one fix (probably among others) was to perform a SEarch. In
fact, it's sufficient to issue a blank "BC seXC " SEarch command with a file
open. (With a file open, a blank "BC seXC " -- i.e. no target $tring specified
for the SEarch function -- doesn't generate an error beep or any change in
VA$ER. Who cares, right? Absolutely useless -- except that, it enables an
Ascii-0 to be the separator character in an XS parse! Haven't the faintest
idea why. Wonders never cease.) So I stuck the following code in STARTUP.INT,
and now all these CMline capture routines work great:

 (assumption: default nw=1 has already been set within STARTUP.INT)
 "BC ca conXC BC seXC BC abXC "

Obviously, Ascii-0 is important to XyWrite internally. It's coded in the
Save/Get memory buffer (and in the "MY.SGT" library), to signal the beginning
and end of individual routines; also in the keyboard buffer and screen
controller strings. On occasions when Xy goes haywire and the screen starts to
look like a blinking low memory dump, I think its because an Ascii-0 or 253 has
been inserted among bad company (bad characters, if you will).

I rather like this CMLINE.PM routine; its quite succinct now... (v3.55+ only).

*Enclosed File: CMLINE.PM