Re: New XYENC 1/13/09 release

[wbass@xxxxxxxx]

Carl Distefano wrote on Sat, 17 Jan 2009 01:21:30 -0500

>Congratulations on the new release.

Thanks.

>Wally Bass wrote on Fri, 16 Jan 2009 03:45:33 -0700

>>I often follow a practice of commenting such things thusly

>>BC ch /this/that/XC BC this is a comment#

>>where the "#" at the end of each line is a 3 byte 0FFh
>>character. ... a 3 byte 0FFh at the end of each line is
>>essential to keep the CR at line end from doing its usual
>>"execute" function, and trying to "execute" the comments.

>>...

>>I wanted to be sure that this technique is still valid in
>>XyWrite IV. Please let me know if it's not, and I will
>>stop this practice.

>Unfortunately, this does NOT work in Xy4.

Thanks very much for checking on that, Carl. I'm sorry to hear that. I'll
start working on a new release to purge the release of the practice.

BTW, in doing another release, I'm thinking I'll combine the 5 XYENC
modules into one, with both the L,H,LH suffix nuances and the line
breaking being controlled by parameters after the 2nd filename. The line
breaking parm would be a 2 digit number between 10 and 99, giving the user
a choice of line lengths. And you could either have/not have line breaking
on any the different L,H,LH options. Does that seem acceptable to you?

>An alternate way that does work in both Xy3 and Xy4 is to
>put a WAIT command immediately before the CrLf. ...

Well, I'm thinking that what I was doing was already obscure enough -- I
think I'd rather head in the direction of simplity rather than more
complexity. All of this can just add confustion for users, after all. I
think I'll just go back to the old practice of putting in a label with a
CRLF inside to break up those kinds of lines. It means that you have to
use expanded mode momentarily for that kind of content, but expanded mode
does work okay for that kind of content, so I don't see that as a big
problem.

>I'm experiencing some miscues with QDF1.PM, especially in
>Xy4, but also in Xy3 in some instances. I haven't had a
>chance to pin down the problems, yet; will do so as soon as
>I can.

Okay. Unfortunately, I've seen XyWrite III make data errors occasionally
when you bombard it with change commands the way that QDF1 does, so don't
assume that it can't be a XyWrite problem. Let me know what you figure
out. But QDF1 is definitely a rather hueristic thing whose work you should
always be a little suspicious of.

Particularly, when QDF1 goes off and searchs for a ~