Re: Chain Printing & Other Bugs

[Robert Holmgren]

Jim, I *know* that you personally have given a lot of time and thought to the
problems I've raised. But publicly, I've tried to focus on questions that are
general or theoretical, and interesting (actually or potentially) to other
users also. I've never needled you about self-centered|exclusively personal
issues. Moreover -- fundamental point here -- they're not "my" problems.
They're *your* problems! They came with the product I bought from TTG.
Variances from the manual. Omissions in the manual. Variances from the
obvious intentions of the program designers. Unannounced variances from past
practice. Bugs, often unknown to TTG (aka "you" -- nothing personal).
Moreover Jim, I do take some care, at a cost in time & trouble, to make
reasonably sure that I am "right" before I speak. So yes, I'm an "individual"
-- not The New York Times or Boston Globe -- but I presume that default BK=1
clogs their disks as well as mine. Don't we all share an interest in making
XyWrite better, to be what it promises? Part of the difficulty is that XyWrite
promises so very much.

 One point, Jim, where I take sharp exception: I am NOT asking for a full
array of personal bug fixes or immediate solutions. And if a problem is due to
my error, then I'm appreciative that you take the time to straighten me out.
BUT... I think that I *do* have a RIGHT to expect that a full-featured word
processor will compile an index or table of contents and print it to paper.
TTG promotional literature says that XyWrite is capable of these CORE TASKS.
Core tasks should WORK, no excuses! If I can't translate keystrokes into a
piece of printed paper, then what's the point?

 My base complaint is that XyQuest is NOT making a distinction about severity,
or providing a SOLUTION to this CORE PROBLEM in a timely manner. By "timely",
I mean a duration that allows me -- and the myriad of other poor deluded users
who believe that XyWrite can compile an index across several files and print it
on paper -- to complete the core task postponed by the bug and still meet my
real-world obligations to write and print; a brief period of time that doesn't
oblige me to learn a different substitute word processor in order to do my
work. I cannot adequately express my RESENTMENT at having to learn MSWord last
spring, because I and my Europe-based colleagues couldn't print under XyWrite
IV. That's what I face again, now, entering my FIFTH week of waiting for a
chain printing fix.

 To my mind, a couple of days is a reasonable time allowance to patch a problem
like this chain printing. XyQuest owns the code of Sig, which isn't broken, to
compare to the Xy4 code -- a TREMENDOUS ADVANTAGE considering that Sig & Xy4
are nearly identical products. However, you might contest that time estimate.
Need an extra day or two? Hey, I'm flexible. But YOU HAVE TO FIX IT ANYWAY,
right? Despite "resource deficiencies"? So why not fix it now. That's how I
see it.

 BUT ... XyQuest's longstanding practice is very different, I think. XyQuest
collects big batches of bug fixes, & issues them via very *IN*frequent version
upgrades. Users appear to have virtually no hope of "quick fixes".
         ****************
  I believe that TTG does *not intend* to respond promptly
  with a fix for this chain printing problem. Never intended to!
  Just stringing me along with that "we'll call you back before
  noon" stuff (a call that never came).
         ****************
 I'm sorry to say that I even doubt, if TTG found the bug and fixed it, that
TTG would recompile or patch, and send the resultant EXE to me. Please correct
me if these are invalid assumptions -- or surprise me by posting a patched EXE
on this board! I think its "against XyQuest principles" to produce
personalized, interim-fix EXEs, public or private, and HAS BEEN FOR YEARS. You
are disingenuous, I think, to suggest that XyQuest responded with personal bug
fixes prior to 12 months ago. (Of course, I'm only guessing; but I never heard
of one.) Consider: v3.55 was the current version for almost 18 months, if
memory serves me correctly (and a mighty bug-infestation 3.55 was, too --
albeit fondly remembered; I do like XyWrite, you know). Sig v1.02 was 11
months old when it was superseded. v4.014 is now six months old. These stats
do not smack of any historic rush to fix -- but rather of a dogged
we've-got-our-own-timetable!

 I know that I lost face, time, and money when I waited and waited last
spring-summer for "as soon as possible" fixes that simply didn't arrive --
indeed my problems were identified around the 18th of May, and the purported
fix contained in v4.014 arrived at my home in late July (by which time I had
long since abandoned the use of XyWrite for this project). Surely you can
imagine how much work is wasted if you prepare a manuscript down to the last
detail, and then are unable to print it with that word processor. Stupid me,
to have had simple faith that XyWrite would work, and not tested at interim
stages in the polishing process. Even stupider, to have committed the same
error of good faith a second time early last month! The chain-printing problem
persists in the v4.015 that Baltimore is running (or was running 4 weeks ago)
in the office -- so am I looking at v4.016 (if there ever is one) for a chain
printing fix?

 Thus, when you say that there are too many MoDe statements in the files, of
course it *is* diagnostic, and ordinarily I'd be interested and appreciative of
the 3 hours you put into ascertaining that fact; but its also sort of like
saying there are too many lower-case "p"s. Should I replace them with "q"s --
or what?

 As for the "hundreds upon hundreds of questions" you've answered for me, well,
questions about what? My love life? My car? My taxes? No: questions about
"your" word processor, usually when it was malfunctioning. Frequently
formulated as "questions" solely to be polite non-accusatory and positive, and
to play along with your flattering default assumption of User Error -- in fact,
most were obvious bugs, and I was just reporting|documenting them, because I'd
gone to the (unsalaried) trouble of investigating them (why should you reinvent
the wheel?). Moreover, if I *don't* document carefully and ad nauseum, you
treat mere suggestions as dubious information. It's simply infuriating. Take
this bloody frame:

{{C,pulldown}} This is a test pulldown frame. Typically it provides Help text.
Alternatively, it might display embedded info like ®VN$DG¯
Thank you.

{{M,xpulldown}}
;Terminate display of "Cpulldown"

Stick that in Xy4's U2. Does it work? Yes. Now stick it in XyWin's U3 or DLG
or whatever. Does it work? No. Like I said (point #6, msg #9305): What
replaces C-frames in XyWin? I implicitly assume that XyQuest *knows* that
C-frames no longer work -- because, after all, XyQuest disabled them! There
must be an intention that something else should replace C-frames. What is that
something else? Don't thrown in my face that you answer hundreds of questions.
Who the hell am I supposed to ask? Who created the questions? Who made
changes but omitted to document them? Puh-leeze! Enough already