[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

BAGGAGE.PM ERROR



Harry, there was an extra ≪EI≫ in BAGGAGE.PM; maybe that caused the problem,
though I can't reproduce it with or without.

 Basically, argument "2" does two things: it checks to see if VA$DF == 0 or 1.
If it's 0 then no text is DeFined, so BAGGAGE branches off to do an UnDelete;
but if it's 1 then BAGGAGE assumes there's a DeFined block in the current
window.

 For no good reason, XyQuest forgot to "finish" designing variable VA$DF. In
Nota Bene, VA$DF == 1 when a DeFined block is opened (first DF), then
increments to VA$DF == 2 when the DeFined block is closed (second DF issued).
But in XyWrite, VA$DF remains equal to 1 whether the block is closed or not (if
not, of course, there's an error). Which renders VA$DF less useful than it
might be (to put it politely -- numerous people have pointed this out over the
last couple years, but they don't fix nuthin no more, maybe because VERY FEW
PEOPLE COMPLAIN ABOUT IT!!). Where was I? What I should have done in BAGGAGE
is something prophylactic, maybe check whether VA$DS and VA$DN are both >0 and
VA$DS<>VA$DN, before trying to copy a DF block into the BAGGAGE garbage dump
[BAGGAGE was originally called GARBAGE, a better name]. But instead BAGGAGE
just plows ahead, tries to CoPy, then checks to see if CP changed. Primitive,
but it works.

 Anyway, I'm trying hard, but I'm not able, to force the "No defined|deleted
text" error message to occur, except when 1) DeFine isn't closed, or 2) I've
not yet rubbed-out text during the current editing session (thus,
VA{Ascii-64}{Ascii-2} is empty).

 I made a few minor changes to the file, as well as the above-mentioned fix.
It's nclosed as BAGGAGE.ZIP...

 As to "DEFAULT xx=n,xx=n,...", I've never used it, first, because VAHS Header
Size is unpredictable, but more basically -- a long time ago (before 3Plus?) I
had persistent problems where XyWrite simply wouldn't evaluate a long string of
DeFault settings in the .PRN file (in the related form "DF xx=n,xx=n,..."). Xy
would read up to certain settings but not past them (I think "HV" was one
problem). When I restored the settings to separate lines, they all worked
again. Voodoo. But it seems to work OK on the CMline; and you're right, a
string of commands is certainly faster.

*Enclosed File: BAGGAGE.ZIP