>>Terry,
>>
>>I see you got it to work ok mixing both methods. You can also put in a poller loop looking for the window title and not launch the second until the first finishes. This requires you to know the exact window title though...
>>You can look at the VFP6 Help On Top article on my website to get those API calls.
>>
>>declare integer Sleep in win32api integer iMilliseconds
>>
>>

ShellExecute creator
>>code
>>llDone = .f.
>>do while ! llDone
>>   llDone = ( FindWindow( .null., "Your Exact Window Title Here" ) = 0 )
>>   if ( ! llDone )
>>      Sleep( 1000 ) && or inkey( 1 )
>>   endif
>>endif
>>ShellExecute destination

>>
>>>I am usint the ShellExecute() function from the Win32 API. I followed David Frankenbach's excelent example and wrapper class. My problem is that I call the function to create a "pdf" file and then load that "pdf" into Acrobat for eMail. What is happening is that the program I use to create the "pdf" cannot create the file as Acrobat gains control of it before it can be created. In schematic format the code looks like this:
>>>
>>>ShellExecute creatorpgm source destination.pdf
>>>small code
>>>small code
>>>small code
>>>ShellExecute destination.pdf - this calls the associated Acrobat
>>>
>>>The ShellExecute function is not fininshing the first instanc before starting the second thus causing the conflict.
>>>
>>>Can anyone give me a suggestion on how to get the thing to work sequentially.
>

I'd investigate using either the ShellExecuteEx() API call, which can return a valid Process handle; you could use that process handle to monitor for application completion (see my API_APPRUN class in the Files Section of UT and look at the method I use to monitor a launched application using tha process handle in the LaunchAppAndWait method; the pseudo-handle returned by ShellExecute() can't be used for this purpose), or incorporating the Windows Scripting Host into your application; the Wscript.Shell object has a Run method which can be used to wait on the launched appliction to run (the last parameter is a logical which can force the app to terminate before returning control to the application/script invoking the run method.)

>Thanks David
>I'll explore it. These can be tricky little buggers huh!
>Terry