Weird handling of openfiles (was Issue with opening PDF file from FilePro)

[Kenneth Brody]

Boaz Bezborodko wrote:
> Kenneth Brody wrote:
>> Boaz Bezborodko wrote:
>> [...]
>>> I decided to peek into what the different machines showed as the file 
>>> status that was returned by OPEN() and found that the machines that 
>>> had the problems always returned a 'valid' file handle ('1' ) even 
>>> though it was not possible for it to be available from the very 
>>> beginning.  The machines that worked gave a negative number until the 
>>> file was ready.
>> If OPEN() returned 1, then the open succeeded.  Why do you believe 
>> that it "was not possible" to succeed?
[...]
> In this case the problem comes up when Adobe attempts to read the file 
> and gives an error that the file is damaged.  In addition to the handle 
> of the file I also had the program output the size of the file and it 
> shows the file as being available even when all the data isn't there.

"All the data isn't there" does not prevent a file from being opened, nor 
having its size determined.

 > I
> also confirmed this by trying ot open the file in Adobe as the file was 
> being built and once it was done.  So long as all the data wasn't in the 
> file Adobe gave me the damaged file error.  Once all the data was in the 
> file Adobe could open it without an error.

So, why do you believe that is "was not possible" for filePro's OPEN() to 
succeed, as you state in the first paragraph above?

> I pretty sure that this is a problem with some of my Windows 
> installations and not an FP problem since Adobe responds differently on 
> the computers which give the proper file status response.  When I try to 
[...]

Yes, your basic problem is that you need to know when the file has finished 
being populated with data, as opposed to whether the file exists or not. 
For that, I would recommend trying the methods suggested by Bob Rasmussen, 
as it is his program doing the populating.

-- 
Kenneth Brody