Re: Versions of Xy2pdf

["Patricia M. Godfrey" priscamg@xxxxxxxx]

Robert Holmgren wrote:

Well, I wouldn't "paste" anything (not Windows Paste anyway); I'd load an
original U2 file and copy blocks of code within XyWrite.
That was what I meant.
Then it must be hardware-related

Why?

Well, the error message was citing the use of an
illegal memory address; so I assumed a shortage of RAM
(though, as I said, this is the most RAM-full system
here: 512 Mb and only running W98SE, and an additional
32 Mb for VGA). But it looks as if it was an artificial
shortage, caused by WP's memory-gobbling ways.
OK, I do see one problem, and it may be your problem. On about the sixth line
of the Xy2PDF frame, you'll see the statement >. DeFine that, and
MoVe it to the very beginning of the frame (right after the opening Ascii-2).
Problem: If you're not setting S/G 652 either manually or via frame GetXyOS in
STARTUP.INT, then frame GetXyOS is run here as the first order of business.
And GetXyOS wipes out S/G 50, which is the filename argument in, e.g., "XY2PDF
SAMPLE". Since I always set S/G 652 in STARTUP.INT, I've never run
into that problem, but this is plainly an error on my part.
Done.

Note that you canNOT argue "XY2PDF E:SAMPLE". No "d:[\path\]" is allowed! The
result file is written in the same directory as the source file.
 If you have
source SAMPLE.XY in E:\DOCS, then result SAMPLE.PDF will be written in E:\DOCS.

Well, sorry, but it isn't. Even after moving
>. The source file is always in a directory
on drive e: (or, occasionally, f:) to which I have
previously CD'd within Xy (Command cd e:\xyinfo\2006);
but the resulting PDF is in Editor's directory
(d:\xyw4dos), to which I have CD'd and logged in before
running Xy by way of a batch file:
cd d:\xyw4dos
d:
editor).
I am fanatical about keeping apps and data separate.
I just looked closely at the code of XY2PDf, and while
most of it is way over my head, I do see

...+"\">
And later it looks as if those are the SGs that are
concatenated (++".PDF")to make the name of
the output PDF. So wouldn't that put the PDF in the
default directory (i.e., Editor.exe's), not the
directory of the file we're converting? Or am I misreading?

Note also that the "d:filename" format you often mention in your messages,
while legal in many circumstances (and frequently cited in XyWrite manuals), is
a risky one. If you're going to mention a disk "d:" then you should usually
also mention the fully-qualified \path\; absent a \path\, you will simply write
the output in what XyWrite deems to be the current directory for that drive
(which, presumably, is not the current drive, and therefore you'll have to
remember, because XyWrite won't display the name of that directory -- indeed,
the only way to see the name of that directory would be to open a NEw window
and then switch to "E:" or whatever -- very tortured!).
Except that Xy "knows" and I know which are the current
directories of all drives. I'm very careful about that.
See the screed above about CDing. So, given that
situation (logged into \xyw4dos on d: and onto d:, cd'd
into a given directory on e:), isn't it true that if I
want to refer to a file in d:\xyw4dos, I just name it
(e.g., CA XyWWWEB.U2); if I want to refer to one in the
logged directory of e: or f:, I just need to prefix the
drive letter (ca e:readme.xyt)? Or are you saying that
many of your routines are expecting fully qualified
path names, regardless of previously issued DOS-Xy CD
commands? Obviously, if I'm calling a file in any OTHER
directory on d: (very rarely) or e: or f: (not
infrequently), I do use the fully qualified path name.
And when I want to do something in XPL with a file I
need to get the fully qualified pathname at runtime (as
in this snippet from my Xytowp program:

>>>

(And yes, I realize that's going to go off the rails if
the directory has a period in its name. I'm still
polishing it.)

I should perhaps make clear that applications, such as
Xy, are ALWAYS on either drive c: (but NOT in
c:\Program Files) or drive D:, in their own
directories. Data (i.e., documents I'm working on) are
ALWAYS on e: (or f:; or, just occasionally, on the
systems where DOS apps are on C: rather than d:, then
D: will be data). XPL program code is in c: (or
d:)\xyw4dos when it's good to go, on the data drive in
\xyinfo\YYYY while I'm working on it.

And believe it or not, I can still (usually) remember
where I'm at. I don't always type it correctly, but
that's another story.
--
Patricia M. Godfrey
PriscaMG@xxxxxxxx