Issue with opening PDF file from FilePro

[Brian K. White]

Fairlight wrote:
> 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->
>   

Actually what she said was perfect. It might not apply to Boaz, but not 
for any of the reasons you just said.

It's not simply "99% of stuff is async". It's whatever your stuff 
happens to be. Some is async or multithreaded, some isn't, and some can 
be told to behave either way.
If he were running a local printwizard as a command in a batch file or 
other local scripting engine, there are ways to execute a program and 
tell the interpreter to wait for the program to return.
Then it's up to the program to do things synchronously or not 
internally. There's no sense blathering about how wrong that suggestion 
is until it is actually tried with printwizard.
I run into this all the time with the scanning and other client-side 
stuff I do.
As long as printwizard happens to wait for ops to finish before it 
returns, then running PW, and renaming it's output file after it's done, 
and having filepro waiting for the second file to exist(), is perfectly 
good.

Even on Windows, rename is an atomic operation.

-- 
bkw