Thanks,

Would the code below allow the person to "do a few things" (print, save etc) while in Acrobat such that they are forced to close Acrobat before returning to VFP or is the waiting for an exit code really only for launching a remote process and waiting for that remote process to end? i.e. here is the sequence disired:

1) vfp works up data and then fires up Adobe
2) user is presented with Adobe form from which they can print or save the form (assumes they have full Acrobat)
3) user *cannot* toggle back to VFP until Acrobat closes
4) user closes Acrobat and then control returns to VFP

I have a feeling looking at the code that this is NOT what is happening - VFP is always in control because it is in a DO WHILE loop waiting for Adobe to fire up, print and then close - there is no point where the user can interact with Acrobat.

Albert

>Sure, but remember that I am not doing it this way anymore. However, I still have my original code (actually in live version now still) and looking at the code you posted,
>
>Here is a quick synopsis:
>
>Set _vfp.autoyield to our desired setting
>Createprocess launches Adobe Reader
>DoPass Sends the Adobe Form password to Adobe Reader
>Do While exitcode #259 suspends processing in VFP until Adobe process ends
>Close threads
>Return processing to VFP
>Set _vfp.autoyield back to its original setting
>
>It would probably suit you better if you were to create the forms in VFP and when the report is generated, create the pdf. That way the data would be embedded in the pdf form but the form would not be fillable (no fillable fields to worry about the data not storing with the pdf) you would have to control all of that within VFP in a VFP form. Or you could store the xfdf with the pdf and always when relaunching the form launch the xfdf instead of the pdf.