For Ken Frank Re: Development

[holmgrn@xxxxxxxx]

> Where we stray unnecessarily you are entirely
> justified in telling us. Yes there will be
> compromises, but without those compromises the
> product undoubtedly would not exist at all.

Hmmmm. OK, here are three situations that drive me up the wall,
which have nothing to do with prioritizing the
Menu development track, but rather are indicative of a
"remarkably uncommunicative" corporate culture which digests
little of our input, and basically doesn't show much concern for us.

A concrete example is the change in the meaning of wildcard X
that occurred early in the Xy4 era.
Wildcard X used to mean "one byte". You could utilize a single
wildcard X, and you'd receive a very precise, predictable result.
 Then some nincompoop changed the meaning of wX to "one screen
position". As you know, 1-,
2-, and 3-bytes can all occupy a single screen position
(column). This necessitated tortured procedures to determine
what in fact your wildcard X captured or represented -- a
character? a function? a carriage return?
Totally illogical & unnecessary. (When you ask Tech Support
"why the change?", nobody has a clue. There are incessant minor
adjustments to the basic "rules", with no notice given, no
explanations, no rationale, no concern for the subtle impact on
extremely complex setups -- a vast interlocked set of routines
start destructing, and it takes hours to figure out that lo and
behold without notification they changed the meaning of wildcard
X! -- not to mention the energy diverted from work to resolve
gratuitous problems without, practically speaking, any help.
This is one largish reason why Signature bombed. Remember? You
fired Sig up, plugged in your 3+ stuff -- and died in the water.)

If I point out something like wildcard X -- make an ironclad case
-- here's what typically happens. First Tech
Support says it doesn't understand -- "wildcard X works fine for
us! Could you provide some examples?" This is an inevitable
test of will, designed presumably to challenge us to just take
the hint and depart quietly. So, what the heck, you write up a
demo which is irrefutable. "Thank you for your blah blah blah.
We are sympathetic but, unfortunately, this minor matter is not
high priority." In short, go away. No sense asking, well, if
its so bloody "minor", how come you never consult us *beforehand*
whether we *wanted* this dumb change?

Another example. (Which one should I pick?)
Last night I happened upon some old XPL notes from 13 years ago
(II+ era) which mentioned an unimplemented command
"BR(restart condition)--breaks from the program until a character
matching the restart condition is encountered..."
If a genuine WHILE...WEND sort of command, this BR would have
been enormously useful, because using 
ReadCharacter and looping until you meet a condition causes
crashes as often as not (although Tech Support would say,
"But Robert,  works for us!" Yikes. They simply don't
*use* XyWrite!)...

What has BR evolved into? Something you find strewn throughout
DLG in form:
  for example,
  which means, display error
message 596 ("Edit port, printer file or printer name. F9 when
done (Esc=exit)") and then *wait* until the user inputs one of
six specified character codes
(Escape, F9, Ctrl-M, Ctrl-C, Alt-Del, Alt-GreyDel), then resume
execution. So BR throws up error PRompts tailored to specific
situations, usually triggered by the need to make
Menu selections. These messages have zero general utility for a
user -- I mean, you're not very likely to ever throw msg #596 up,
are you? Ditto with the other 1300 msgs. You can't edit them,
or supplement them, because they're hard coded in EDITOR.EXE;
there's no table of them, as there is, say, for accented
characters. In short, these realities together eliminate
once-promising BR as a serviceable tool for users. Now, it is
*possible* that the "#" modifier in