Hi Ed,

Got the command working. Can't recall how it was solved but will monitor whether the problem develops again. Thanks again for your help.

Regards.
>Thanks Ed for the the detail email and the DOCS on using your API functions. I have tried the example and it works beautifully but when I tried on my EXE, it does execute but the communication handshake to the Time Clock machine fails. When I tried this at the DOS prompt no problem at all. Maybe you can give some further tips?
>
>Regards,
>Farouk Yew Abdullah
>
>>>Hi all,
>>>
>>>How do I run a DOS program without showing the MSDos screen; ex: RUN
>>>collect. This collect.EXE is a program to collect data from a Time Clock machine. Another weird thing is after I do RUN, collect.EXE seems to be corrupted after the command.
>>
>>As Paul mentioned, I posted a class a few days ago that will run an external .EXE (DOS, Win16 or Win32) from a VFP program without the RUN command. It uses the Win32 CreateProcess() API call to launch the application, and should provide you with control over it, both from the standpoint of running without a DOS Window appearing, and from the standpoint of being able to shut it down programmatically from your VFP application.
>>
>>When you say that the .EXE file appears corrupted, what indication of corruption are you getting? You may be looking at any of several problems related to the DOS application itself; the three things that come to mind immediately are that , the application may not be shutting down completely and releasing all the resources it grabs, direct hardware accesses performed by the DOS application may be leaving hardware in an unknown state and the application might be using a memory manager that doesn't get along well in the Win32 environment. A bit more information about exactly what the DOS program does, and what seems to indicate that the executable is being corrupted by the RUN command would help here.
>>
>>Of the three problems mentioned above, the class I posted will only help with first; API_APPRUN provides methods that will check the termination code of an application that it launches (the CheckProcessExitCode method allows you to see the exit code returned by an EXE file on termination, or returns a known value if the program is still running), and it provides a way to kill off an executable even if that process hangs (the KillProc method will shut down the process using the Win32 TerminateProcess() API call, which is as close to an absolute kill as you can get without restarting Windows.)
>>
>>Assuming that the executable were in your current working directory, and that you wanted to run the executable in that directory, with no DOS window, and not have VFP wait on the executable to shut down before continuing, the following would work. I've assumed that you've put the class code in a .PRG file called PROCESS.PRG in this example:
>>
>>

>>SET PROCEDURE TO PROCESS ADDITIVE
>>oProc = CREATEOBJ('API_APPRUN','COLLECT.EXE',,'HID')
>>IF oProc.LaunchApp()
>>   *  The program was started successfully
>>ELSE
>>   *  The program didn't start up
>>ENDIF
>>DO CASE
>>CASE ISNULL(oProc.CheckProcessExitCode())
>>   *  The process never started, or Windows is corrupted
>>CASE oProc.CheckProcessExitCode() = 259
>>  *  The program is still running
>>OTHERWISE
>>  *  The program terminated with the exit code returned
>>ENDCASE
>>

>>
>>To run it and force VFP to wait for it to terminate, use oProc.LaunchAppAndWait() instead of oProc.LaunchApp() to start the executable. LaunchAppAndWait() returns a numeric value instead of a logical; 0 indicates the executable wouldn't start, 1 indicates that it ran to completio before returning, and a -1 would indicate that the application started, but the user aborted the wait on termination by pressing the Escape key while VFP was waiting on completion and had focus.
>>
>>You can check the termination code from the process with oProc.CheckProcessExitCode(); this will return either a numeric value giving the executable's last reported status (259 indicates that it's till running) or a NULL if the executable never started, or something quite drastic happened that corrupted one of Windows' internal tables.
>>
>>If the executable has started and just won't shut down, oProc.KillProc() will force Windows to clear the program from memory. If it can't shut it down, the system is pretty well hung, and a cold boot is probably needed.