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

[Boaz Bezborodko]

-------------------------------------------------------------------
> Message: 1
> Date: Wed, 27 May 2009 18:49:42 -0400
> From: "Brian K. White" <brian at aljex.com>
> Subject: Re: Issue with opening PDF file from FilePro
> To: filepro-list at lists.celestial.com
> Message-ID: <4A1DC386.9070507 at aljex.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> Boaz Bezborodko wrote:
>   
>> 2.  How do I check if a file can be opened in R/W mode in FP?
>>
>>     
> ....
> then: form foo{""
> then: printer reset 'release the print job so printwizard can take it
> then: gosub waitpdf  ' wait for pdf to exist and become writeable
> if: pdfok
> then: system "start" < tempfile
> if: not pdfpk
> then: errorbox "Output ("{tempfile{") not created."
> ....
>
>
> waitpdf if:
> then: cs(4,.1)="0" ; c(3,.0) = "300"  ' c*100msec = timeout (300 = 
> 30,000 = 30 sec)
> wploop if:
> then: cs = c/"10" ; show "Waiting" < cs < "for PDF..." ; handle = 
> open(tempfile,"wb")
> pdfok if: handle ge "0"
> then: close handle ; goto ewp
> if: c gt "0"
> then: c = c - "1" ; sleep "100" ; goto wploop
> ewp if:
> then: show "" ; return
>
>
> basically, as per the open() documentation:
> "If the file cannot be opened, a negative number is returned."
>
> So, try to open() in write mode, then see if handle is a negative number.
> As soon as handle is 0 or greater, close(handle) and proceed to use 
> tempfile.
>
> The rest of the stuff is just nice user display and timeout so that it 
> won't wait forever if there is some problem and the pdf will never show up.
> Don't think that 30 seconds is too long. The user would only ever wait 
> that long if the pdf generation failed and the pdf will never show up.
> So you don't want to wait forever and force the user to break out 
> ungracefully, and you also don't want the "I give up waiting" time to be 
> shorter than the worst possible legitimate scenario of a very slow pc on 
> a slow network trying to produce a huge report. That could even be 
> longer that 30 seconds.
>
> You can even get fancier and return a more informative error message by 
> returning the actual error code from handle instead of just waiting for 
> handle to be 0 or greater.
> ie: when handle is a negative number, it's a negative version of the 
> value returned by the OS's open file function. These numbers are defined 
> somewhere (msdn web site?) so a -2 may mean file not found or a -5 may 
> mean insufficient user priviledges, etc... and add in some abort key 
> handling so they can also break out of the wait loop gracefully.
>
>   
I put variations of this code to work and on some machines it still 
didn't work.  I realized that there was a pattern...The machines on 
which it worked before still worked and those that didn't still had the 
same problem.

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.

All are connected to the same server and have almost identical 
environment setups.  I'm at a loss in explaining why some machines are 
properly reporting the file status while others aren't.  It must be 
related to Windows, but I have no idea where to look.

Does anyone have any suggestions?

Boaz