Re: Sig vs. Xy4

[ML Solla d012362c@xxxxxxxx]

I've posted this stuff before, but I think I'll post it again in the
context of both XY4 bugs and comparisons between the 2 dos versions.

When I saw that no one misses the useful little PI command, it dawned
on me that not of all of us here in Babel are working on the same sort
of tower.

I'm a (wince) real estate / probate lawyer. I produce stuff like the
HUD-1 settlement statement with all the little lines and boxes the
government requires. I could buy a $1200 program that produces the
same form (as long as you don't have to change anything) or struggle
along with my old word processor that gives me total control over any-
thing a laser printer can do.

I use rented PCL forms for loan documents. I IN (insert) the printer
ready pcl file at the top of a form (with no space - vers 4 chokes on the
no space argument) and then use PI commands to position the variable
text within the form.

I use xpl to do my bookkeeping. Simple stuff like posting mortgage
receivables and keeping my trust account in balance (much too simple
for commercial accounting programs to handle).

Last but not least - converting III docs to IV is a nightmare
(or as Holmgren would say - a fucking nightmare) I had 10 years of
client documents and 40 megs of forms when Signature and IV
rrived on the scene. I spent 6 months converting my help system
to dlg and U2, but in the end, I found nothing in the new program
that would justify converting a ton of shit painstakingly crafted
over a decade and no improvement in speed or stability.

That said, these are things I can't do in IV (but no problem in III):

preserve the decimal accuracy when adding a column of numbers. eg,
1.00 + 2.00 = 3.00 when added in III (using SM SM DT), but = 3. in
IV.

quirky refresh of cmd line. Sometimes lose the window number box, the
file name, and sometimes get a lingering image of the top of the last
L frame.

failure of the prompt line to clear at the next function call is
distracting. Requires re-coding of xpl routines to end with a 
call.

absolute Y movement of formatted output. In III I can use PI cmd to
send printer code to back up 3 (or whatever) lines and then go from
there. (useful when adding a receipt box at the end of a letter in
the area to the right of whatever enclosures, copies, etc might
run down the left edge) - In IV, the first line of the "backedup"
text prints properly, but the 2nd line returns to the bottom of
the page (because each carriage return adds 50 or whatever units
to the last value instead of just moving down a relative 50.) I
know this is related to the graphic display capacity, but I'd
like to be able to disable graphic display (I don't even load
the screen fonts). Graphic display is of little value when the
text includes PF or IS commands. Graphic display may also be
affecting the problems described in 2 above.

Can't get the proper horizontal spacing after a substitution
character. Eg - if I substitute the string: [esc]*p[series of
pcl instructions] for [box character] and then insert a tab
following the character, the horizontal movement craps out.
Can't overcome the problem by assigning the box character
a width in the width table. And certain substitution characters
(eg a small box) are meant to have no width so that the next
character (like a checkmark or counter) appear within the box
when printed rather than to the right of it. again - can't do
that here. (No doubt related to being able to produce
formatted view on screen)

can't use numbered mode commands to invoke printer features.
Instead of MD10 to invoke bold floating underline, I have to
use a specific printer code to start it and another to stop it
and then add the bold attribute, and then have no visual signal
on the screen that the text is underlined. Some mode colors
(e.g. red) are used to signal something (like a negative balance
in a ledger sheet) but print normally. Can't do that anymore.
Although I've seen nothing produced by the editor that takes
advantage of the additive mode scheme, the former functionality
is replaced by something in your menuing system I have no use for.

The latest version of IV permits an "f" frame in a U2 file, but
the user has to move or tab to the selection, can't just invoke
the action by hitting key that corresponds to the bolded letter
of the menu.

I thought the extensive default file would reduce the number of
commands necessary in the document, but IV requires more commands
than III. Eg PT1 in III takes 3 commands in IV (font, size and
character set). I know that advances in scalable printer technology
have caused you all to re-think printer control, but the solution
is unelegant [sic]. And defaults like top and bottom margins and
page width interfere with forms set up for landscape printing or
forms not containing headers or footers - but needing all the
page area.

Can't change the initial value of the offset anymore. Used to be
able to create a deed form with a "prepared by" header box at the
top of the form with no offset, and then offset the body of the
document following the header - can't do that no more.

this is an odd one: in the xpl program I use to navigate directories,
when a directory is displayed on screen, an enter with the cursor
on a file name calls the file, an enter on ".." or  name
brings up the parent or sub directory. Works an unlimited number
of times in III, but crashes predictably on the fourth iteration
under IV. (and an ascii 175 is dumped at the top of the screen).
Like I said - odd - quirky.


Solla
d012362c@xxxxxxxx