Issue with opening PDF file from FilePro

[Fairlight]

Four score and seven years--eh, screw that!
At about Wed, May 27, 2009 at 03:59:07PM -0400,
Nancy Palmquist blabbed on about:
> Boaz Bezborodko wrote:
> > I'm running FP from Windows and I want to open a PDF file from within FP 
> > that was first generated by FP and then sent to Bob's PrintWizard to 
> > convert into a PDF.  The thing is that I can't figure out how to tell if 
> > the PDF file is ready from withing FP.
> >
> > I don't want to use a long SLEEP command as some files are ready within 
> > a second or two.  But if I open the file too early then Adobe complains 
> > about the file being damaged.
> >
> > Any suggestions?
> >
> > Boaz
> >   
> Boaz,
> 
> Trick is to write to file1, at end of PDF conversion rename the file to 
> file2.
> 
> In filePro, check for exists(file2) eq "1"
> 
> When it exists the file is ready to open.

That is such an utter fallacy, I can't even begin to understand why you
posted it.  In a Windows environment, 99% of your processes will be
non-blocking, asynchronous.  In layman's terms, they process and continue
processing well after the startup of the program.  The only thing the
"return" from them usually indicates is that they're up and started.

The only thing exists() tells you is that the file has been open()'d at the
low level with O_CREAT.  It says -nothing- (let me repeat that:  NOTHING)
about whether or not the complete contents are available, whether or not
the file is still globally locked, etc.

The only surefire way to know -for sure- without using some kind of "cross
your fingers and pray it's within tolerances" sleep/wait methodology is to
use a program that blocks/waits until it's actually done to return.  This
entails -not- closing any console windows and stdout/stderr streams, as is
the normal idiom on Windows.  Most programs don't have this facility.  I
build some things specifically to -not- run in "Windows mode" specifically
to bypass this stumbling block.

Bob posted some solutions for PrintWizard, one of which (read/write mode
testing) depends on the global file locking to be relinquished, thus
substantiating what I'm saying here.

In -any- environment, all exists() tells you is that a command opened the
file "at some point".  It doesn't tell you data was written to it, it
doesn't tell you that all the data is done, it doesn't tell you that the
file is no longer in use, it doesn't even tell you that it was opened by
the same process.  It says the file was created, period.  Depending on
exists() for anything else is a recipe for potential confusion and problems
in *nix environments.  Depending on it for anything else in Windows is a
recipe for an epic fail.

mark->
-- 
"I'm not subtle. I'm not pretty, and I'll piss off a lot of people along
the way. But I'll get the job done" --Captain Matthew Gideon, "Crusade"