>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?

There are some things to check; since it's a DOS program, there are settings that take effect when you open an DOS Windows and start a DOS VDM that may affect how access to hardware is granted, or it may be that something else already has the comm port you need, and the corruption you've reported previously was the .EXE failing to start because of competition for resources.

An MSDOS program actually starts up a separate virtual machine whose behavior is controlled by a .PIF file, that tells Windows about the memory and hardware requirements for the new VDM. The defaults for this depend on where you start the DOS prompt; to find out what it's settings are, examine the .PIF by right clicking on it and selecting Properties; this will bring up its property sheet. The settings of most interest are the Advanced settings on the Program Page and the Memory Page.

VFP, when launching an app, normally uses FOXRUN.PIF, found in VFP's main directory, or in the application's directory if you've constructed one specifically for the application. Compare the Program/Advanced settings and Program/memory settings of your MS-DOS prompt and FOXRUN.PIF; if there are differences, that might explain the problem with FOXRUN. Try adjusting FOXRUN.PIF to match the MSDOS mode in Programs/Advanced and on the memory page and see if your application now runs under VFP. If that makes your application work from inside VFP, then the DOS VDM configuration is what is causing the problem.

API_APPRUN can launch a .PIF rather than launching the application directly if you need settings other than the defaults used for a DOS VDM; you might try constructing a .PIF file for your application by making a shortcut to it, and then having API_APPRUN fire the .PIF file (give the name of the .PIF file rather than the name of the .EXE; the location of the .EXE will be in the .PIF file you construct.) This is the most likely solution to the problem.

It might be helpful to run COLLECT.EXE in other than a hidden window for debugging; simply omit the 'HID" argument to have it run in a normal DOS window. This will let you view any output sent to the screen by the DOS app.

If you fire VFP, and then from the command window, can run your program outside an application, then it's unlikely that your problems with the RUN command were caused only by the .PIF settings.

If you make use of any ActiveX controls, or have other software running while your application is running that may monitor the comm port, these may be the cause of your troubles. Software that I've seen cause problems with DOS apps' accessing comm ports include Microsft's and WinFax's fax drivers, Internet connectivity software and remote control software. If you have these running while your application is up normally, try disabling them and see if the problems disappear.

You still never told us what indication you had from your original message that COLLECT.EXE was corrupt after you launched it from the VFP RUN command; that also might give us some clues about what is happening.

>
>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.