Thanks for the ideas Mike. I did test that. I double-clicked on the .xfdf file in windows explorer. Adobe Acrobat opened up and loaded the .pdf form and populated it with the data in the .xfdf file. I checked the taskmanager and I only had one instance of acrobat running. Then I closed it and the process terminated as it should and no longer showed up in windows task manager.

Then I did the same thing with the .pdf and then again just clicking on the .exe file. All worked fine. I even tested using the Acrobat Reader shortcut on the desktop and added the command line parameter to the .exe path pointing to my .xfdf file and then the .pdf file, etc. In all cases it works as it should and when I close acrobat or reader, the .exe dissappears from the windows task manager as it should.

I checked in my .prg where I run it and everything opens up fine and my apps waits. While adobe is running (either acrobat or reader) there is only one instance under processes. When I close it, either acrobat or acrord32 remain under processes in the windows task manager because it does not end the process even though the app appears to exit. Waitforsingleobject continues to wait.

I have never seen this happen. It happens just instantiating acrobat or acrobat reader using createprocess too...

I have rebooted and verified they are not running before I run the test.

I'm stumped!

>>UPDATE: this is weird. I checked the task manager and after closing acrobat, the process acrobat is still running in the task manager. If I stop the process in the task manager, then waitforsingleobject ends as it should and processing continues on in my app after that. Any idea why closing the app would not kill the process? I've never had that happen before and it doesn't happen anyplace else in my app where I use createprocess to run an .exe...
>>
>>I just tested it again using acrord32.exe (hard coding the acrobat reader as the first param as a test) and it does the same thing. After closing the app, the process keeps running in the task manager and I have to kill it...
>>
>>
>>
>>
>>*G* Ok, I can successfully run my .xfdf file in Adobe Acrobat Reader now using these steps. Everything works fine, EXCEPT, waitforsingleobject never stops waiting now. It is stuck waiting indefinitley. This code launches acrobat as it should and the form is populated with the data from the .xfdf file and my program stops processing while acrobat is running as it should, but after I close acrobat, my program continues to wait...it never stops waiting...very strange.
>>
>>Any ideas?
>>
>>

>>#Define ERROR_SUCCESS		0	&& OK
>>DO decl
>>
>>oReg = NEWOBJECT("FileReg",'registry.vcx')
>>cAppKey = ""
>>cAppName = ""
>>m.cExtn = "PDF"
>>nErrNum = oReg.GetAppPath(m.cExtn,@cAppKey,@cAppName)
>>
>>IF m.nErrNum # ERROR_SUCCESS
>>	MESSAGEBOX(C_EXTNOFOUND_LOC)
>>	RETURN
>>ENDIF
>>
>>IF ATC(".EXE",m.cAppName) #0
>>	m.cAppName= ALLTRIM(SUBSTR(m.cAppName,1,ATC(".EXE",m.cAppName)+3))
>>	IF ASC(LEFT(cAppName,1))=34 &&check for long file name in quotes
>>		m.cAppName = SUBSTR(m.cAppName,2)
>>	ENDIF
>>ENDIF
>>
>>*|-- Run REAL App, with file name parameter
>>set DEFAULT TO c:\foxpro\vfp8
>>llacordok = RunAndWait( m.cAppName, '61NC.XFDF', 'C:\FOXPRO\VFP8' )
>>IF !llacordok
>>	=MESSAGEBOX("Unable to print Acord Form.",0+16+4096,"ERROR")
>>ELSE
>>	WAIT WINDOW "Finished Printing" NOWAIT
>>ENDIF
>>
>>PROCEDURE  RunAndWait (lcApp, lcCmdLine, lcdir)
>>#DEFINE INFINITE  0xFFFFFFFF
>>LOCAL lcStartupInfo, lcProcInfo, hProcess, ;
>>	lnPrio, lnIBelieve1
>>lnIBelieve1 = 1   && Don't remember what that was
>>lnPrio = 32 && Priority of Process=Normal
>>lcStartupInfo = CHR(68) + REPLI(CHR(0), 67)
>>lcProcInfo = REPLI(CHR(0), 16)
>>IF CreateProcess(0, m.lcApp+" "+m.lcCmdLine+CHR(0), 0,0,;
>>		m.lnIBelieve1, m.lnPrio,;
>>		0, 0, @lcStartupInfo, @lcProcInfo) <> 0
>>	* process and thread handles returned in ProcInfo structure
>>	hProcess = buf2dword(SUBSTR(lcProcInfo, 1,4))
>>	hThread = buf2dword(SUBSTR(lcProcInfo, 5,4))
>>	* waiting until the termination
>>	set STEP on
>>	= WaitForSingleObject(hProcess, INFINITE)
>>	= CloseHandle(hThread)
>>	= CloseHandle(hProcess)
>>ELSE
>>	RETURN .F.
>>ENDIF
>>RETURN
>>
>>PROCEDURE DECL
>>DECLARE INTEGER CreateProcess IN kernel32;
>>	INTEGER lpAppName, STRING lpCmdLine, INTEGER lpProcAttr,;
>>	INTEGER lpThrAttr, INTEGER bInhHandles, INTEGER dwCrFlags,;
>>	INTEGER lpEnvir, INTEGER lpCurDir, ;
>>	STRING @lpStInfo, STRING @lpProcInfo
>>DECLARE INTEGER GetLastError IN kernel32
>>DECLARE INTEGER CloseHandle IN kernel32 INTEGER hObject
>>DECLARE INTEGER WaitForSingleObject IN kernel32;
>>	INTEGER hHandle, INTEGER dwMilliseconds
>>RETURN
>>
>>FUNCTION buf2dword(lcBuffer)
>>		RETURN ASC(SUBSTR(lcBuffer, 1,1)) + ;
>>		ASC(SUBSTR(lcBuffer, 2,1)) * 256 +;
>>		ASC(SUBSTR(lcBuffer, 3,1)) * 65536 +;
>>		ASC(SUBSTR(lcBuffer, 4,1)) * 16777216
>>RETURN
>>
>>

>
>Tracy,
>
>The first thing I'd do is reboot, and then perform a simple tests from Windows Explorer:
>
>- open the Windows Task Manager and check for presence of Acrobat
>- launch the document in question from Explorer
>- confirm that Acrobat appears in task mgr
>- close the app and confirm that Acrobat (or whatever, acrord32.exe, etc.) goes away
>
>If Acrobat doesn't go away, then that problem needs to be investigated, irrespective of your VFP app.
>
>Otherwise, I'm not sure why closing the app doesn't release the process, but bear in mind that Acrobat (at least the versions I'm familiar with) is an MDI app. If Acrobat is already open, when you launch it again against another document, the processid returned from CreateProcess is not useful. What mystifies me is that you say your app keeps waiting, but I would expect it to behave as though the second instance immediately terminated. In any case, waiting on process termination would not work if there are multiple instances of Acrobat windows opened, because they all end up being owned by a single process (the first one that was launched).
>
>Mike