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

Re: v3-4 dual use gotcha

On 24-JAN-1996 13:38:32.0 xywrite said to LESLIE319
  >Leslie writes: "I wouldn't set 1a=0 permanently--doing so creates some
  >other problems, especially having to do with embedded footnotes."

  >Leslie: Did you perchance mean 1a=1? 1A=0 is the zap-what-follows-eof
  >hard-coded in previous versions. I've never done anything with y3, so
  >no prob there. ...

  Yes yes yes. Sorry, Annie. If you leave the EOFs zapped, you're
golden. It's 1A=1 that causeth problems.

  >Don't know why I should encounter more my share of xyW eof conflicts,
  >but I seem to, going back to the '80s. I've used a stripper ever since
  >for crossplatform files. So I was excited to see the v4 1A option, but
  >noted the documentation's warnings: Don't set it to 1 (ignore midfile
  >eofs) if you have Document Info turned on. I've had Doc Info turned
  >off from the start, but suspect that Robert hasn't, and that that
  >accounts for: "I remember two specific problems with 1A=1. I would
  >often find that files imported from outside or else edited earlier
  >with 1A=0 suddenly acquired a tail of Document Information (the IO=1
  >stuff) as a constituent part of the document. [...]"

  Robert's no doubt correct. There are also problems with fns.

  >When 1A is set at 1 and you open a loaded config file (.mnu, .dlg,
  >etc.), a lot of binary garbage is displayed at the end. If you work on
  >one and save while it's loaded, presumably the garbage is saved too as
  >if it were text. So I work on a copy, and to test I overwrite the
  >loaded file and reload the new version--which probably should be done
  >in any event.

  Sounds sane. I use 1A=1 when WordPerfect files are incorrectly prepared
and crash Word for Word. It's the only way you can get at the critters.

  >In a discussion of xyW's eof a few months ago, someone asked asked why
  >xyW still uses what the doubter characterized as the archaic eof
  >convention. I think this situation explains why. Previous versions
  >haven't let you see the memory data that xyW appends to a loaded
  >config file, and if you save one that's loaded, the 1A zaps the binary
  >stuff that follows. v4 lets you see that stuff if you set 1A at 1, but
  >you must take the binary stuff into account.
  >I've complained about v4 taking choices that were present before out of
  >users' hands, but in this case v4 gives you a new chance to hang
  >yourself if you're not careful. I'm glad it does, just wish the
  >documentation were more thorough.    --A

  I suspect it's something the old mgt. threw into Signature to make IBM
happy and it's just been lurking there bugs and all, ever since.


`[1;35;43mRainbow V 1.19.1 for Delphi - Registered