Yea that is what I am aiming for. However I need to know how long to keep the form up.

I am currently trying EmunJobs, an API that tells me how many print jobs I have in the print que.

I will EnumJobs before ShellExecute, wait for a time delay for the application (Adobe acrobat) to start and begin printing. Then I will loop checking EnumJobs until it is back to the original number.

Or I can call EnumJobs storing original number of jobs, run ShellExecute, loop around EnumJobs until it increases (showing that the report is priniting), goto a second loop around EnumJobs until it goes down one.

Fine except that if the original cout is greater than zero I will not know which one is finished first first. I will have to wait until the count drops to zero.

Also I will have to add a drop dead timr in case the que is backed up.

Not very elegant.

>You were probably looking for a better answer but this is just off the top of my head. What about a simple little form that says 'Printing....' or whatever and on a timer event simply adds little dots to the end. If the dots reach a certain length then start over. It's been my experience that as long as the user sees something on the screen moving in front of them they'll hold on.
>
>Aloha,
>
>James
>>I create a PDF file of all reports using amyuni. This PDF is saved and made available for people to send report by email. Also I like the preview supplied by the PDF reader better than the one native to VFP.
>>
>>Some reports are made up of more than one form. Printing to PDF consolidates the multiple parts into one file so there is no chance another print job will come between the two parts.
>>
>>So I decided to print the PDF in all cases.
>>
>>I print the PDF file using the API function ShellExecute so I do not have to worry about what PDF file reader is printing the report. When I call ShellExecute to print the PDF file control is immediately returned to VFP.
>>
>>Some reports can take minutes to print. This means that the user is left in limbo wondering if the report is printing. I have had users who had enough time to print the same report more than once because they did not think it printed the first time.
>>
>>I tried a simple timing loop. I timed how long the report took to create a PDF file and multiplied that time by a constant and added a bias time, say 3*nRunTime + 10 secs. I them called a thermometer type program to give a progress bar.
>>
>>However this works for shorter reports not longer ones which seem to have a variable element I cannot nail down. Sometimes it is too much time - sometimes it is not enough.
>>
>>Can anyone suggest another way to tell how long the report will take to print or if the report is still printing? Is there an API function which does one or both?