Re: Subject: Re: pdf2xy routine

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Patricia M Godfrey  on Tue, 11 Jan
2005 11:38:29 -0500


> Path: here's the result of piping the path command to a text file:
> PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PROGRA~1\WIN98RK;C:\GS\GS8.15\BIN

FYI, always put a semi-colon after the last spec:
 PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PROGRA~1\WIN98RK;C:\GS\GS8.15\BIN;

> the resulting "actual command being issued to
> DOS and GS " reads like this:
> dos/nv/x/z /c -output D:\XYW4DOS\VIEWPDF.TMP "c:\GS\gs8.15"

Ah, very good work, Patricia -- precisely what we want. OK, hmmm: indeed, as
the OpSys reported, there is both "bad command" AND "bad file name" -- because
it is *missing* altogether. It _should_ read thus:

dos/nv/x/z /c C:\GS\gs8.15\bin\PSTOTXT3.EXE -output D:\XYW4DOS\VIEWPDF.TMP
"d:\path\sourcefilename.PDF"

where d:\path\sourcefilename.pdf is whatever you specified when you issued the
command. Ummm, what exactly is the command you are giving? I say something
like:
 PDF2XY POEM.PDF
where POEM.PDF is in my current directory. And the result is (this is actual):
 dos/nv/x/z /c F:\GS\GS8.15\BIN\PSTOTXT3.EXE -output G:\XY4\VIEWPDF.TMP
"G:\XY4\POEM.PDF"

So let me look one more time at your REG data... ok, they're fine, nothing
wrong there. And you're using the PDF2XY frame dated (Last Revision) "3/3/04"
-- correct?

In that case, the only conclusion I can reach is that EITHER you're issuing a
bad command to begin with, OR you have OOM problems that are preventing the
REGistry from being read correctly. If the latter, there are things you can
do...

What exactly is the form of the command you're issuing to launch PDF2XY?
(Could very well be OOM here... I can't get this frame to NOT work right! It
plain works -- for me.) You could insert something like
>> right before the single instance of
> (then LOADHELP). Save/Get 15 is wrong here, obviously. It's
empty, whereas it should contain the path+filename to PSTOTXT3.EXE. After the
routine ends, you could check the values of S/G 100 and 101 -- 100 should be
particularly interesting... (VA/NV @100). Work your way backward in the
frame -- try to find out where the info that should end up in S/G 15 goes
"missing". There is one call to RegData -- see what the content is coming out
of that call, right after >, grab S/G 50 (>) and
see what's in S/G 101. These are simple debugging techniques -- and it's
easier for you to do them than for ua, at long distance.

Let us know.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------