Issue with opening PDF file from FilePro

[Brian K. White]

Boaz Bezborodko wrote:
> Kenneth Brody wrote:
>   
>> Boaz Bezborodko wrote:
>> [...]
>>     
>>> 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.
>>>       
>> Define "available".
>>
>> You still haven't explained why you feel that is "was not possible" 
>> for filePro's OPEN() to succeed.
>>
>>     
> According to the way one set of machines handle it, when Adobe Reader 
> tries to open the file or when Windows tries to rename it, it gives an 
> error that the file action cannot be taken because another application 
> has accessed the file.  But the other when the others try to access the 
> file under the exact same circumstances then Adobe gives a file-damaged 
> error and the Windows rename seems to be ignored.
>
> On the machines where a file-is-being-accessed error appears FP gives a 
> negative number for OPEN().  On the other machines the result is always 
> "1" even if the file is being written to by another application (in this 
> case PrintWizard).  It seems to me that the first set of machines are 
> responding correctly and the second set is not.  FP just seems to be 
> giving the status that the OS is returning to it.
>
>   

You still haven't answered his question.

On what facts do you base the supposition that the file should not 
possibly be able to be opened in write mode?

The fact that Acrobat can open a file in read mode on some machines and 
not on others means nothing. We don't know what exactly acrobat does, we 
don't know what different versions of acrobat do, we don't know what the 
versions of your workstation OS's are nor the full list of all windows 
updates applied, we don't know the details of the networking setup wrt 
caching and locking. We don't
You don't _really_ know what exactly printwizard is doing or how, or 
when, or how long it's various actions will take and which if any 
actions are garanteed to happen serially and you haven't said enough for 
us to be sure that you're using file names that are certain to be unique 
per invocation, nor have you said enough for us to know  that  the busy  
file really already exists and wasn't perhaps created on the spot by the 
open().

You have what _appears_ to be a file locking problem, but so far it's 
just an appearance based on a lot of assumptions.
So start by removing as many question marks as possible and test just 
file locking to prove if that's really what's going on or not.
That was the point of the two all-filepro tests I suggested. We know how 
fp behaves and if you write your own simple test in fp, then you do know 
all the things you don't know above.
That would be an answer to the question.

The debugging tree goes out from there, but doesn't go anywhere unless 
it starts from there.
Right now we only know that the whole combination of  fp + pw + windows 
+ your code isn't working, which isn't useful.

-- 
bkw