Issue with opening PDF file from FilePro

[Fairlight]

On Fri, May 29, 2009 at 10:37:33PM -0400, Boaz Bezborodko, the prominent pundit,
witicized:
> Kenneth Brody wrote:
> > Boaz Bezborodko wrote:
> > [...]
> >> While I'm trying to nail this down I will probably try something a 
> >> little different.  I'll send two jobs to PW about a second apart and 
> >> look for the second one.  When it appears then the first must have 
> >> been completed already so it is good to go.
> >
> > Sounds rather kludgey to me.
> >
> > 1 - Can you guarantee that jobs are run in serial?  (That is, once job 
> > A starts, job B won't start until job A completes.)
> >
> > 2 - Can you guarantee that the second job won't start first?
> >
> > If you can guarantee #1, then you can force #2 by not submitting the 
> > second job until the output file from the first job exists.
> >
> > As I said, rather kludgey.

The whole thing is rather kludgy, but that's the nature of running async
windows apps. :/ Which really is little different than running a process in
the background in *nix, but at least you get a choice in *nix.

> Bob told me that I can't guarantee that the two would be run 
> sequentially, but he did suggest setting up the print file to generate a 
> second PDF file which would then run in the same thread and only be 
> processed after the first is completed.  It was a simple process to add 
> a line at the end of the existing print file to have PW create a second 
> PDF file.  The process then looks for the existence of that second file.
> 
> This will work whether or not I have a problem with Windows reporting a 
> file available when it shouldn't be.

Well the following is -still- subject to a race condition, but it's the
best you're going to get, given the problems you're facing:

1) Check for file's existance with exists().  If it's there, open it.  If
you can open it read/write, then:

2) Check the file's size with FILESIZE() on the opened handle.

3) Institute a loop that sleeps for one second.  Close the file, re-open
it, and check FILESIZE() each iteration.  If you go a second with no new
data, you're -probably- safe to exit the loop and proceed onwards.

NOTE:  I do -not- like this solution, as it IS still subject to a race
condition.  And if you don't close/re-open the file between checks, be
it on your own head; I'm 50/50 as to whether or not FILESIZE() will pick
up on changes to the file's size once it's opened--depends how it's done
internally.  This could be OS-dependant, or it may be absolute behaviour,
and only Ken can answer that.

That said, it -should- give reasonably consistent results if you check the
actual size over time.

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"