>>>>>>>One of the solutions is:
>>>>>>>

>>>>>>>DECLARE INTEGER WinExec IN win32api ;
>>>>>>>   STRING command, INTEGER nShow
>>>>>>>
>>>>>>>=WinExec("exename.exe parameter",1)

>>>>>>
>>>>>>Yuri,
>>>>>>
>>>>>>This function is provided strictly for backward compatibility with Win16 based apps.
>>>>>
>>>>>Thank you, George. Good to know it.
>>>>>By the way, so happened, I currently support projects which were created long time ago, gradually being updated when needed, and which have winexe in many VFP8 modules. What would be your recommendation? To replace all Winexec there (just in case) or leave them as is?
>>>>
>>>>Yuri,
>>>>
>>>>Basically, I'd say that "if it ain't broke, don't fix it". However, in the future, I'd recommend either the ShellExecute() function or using the WScript.Shell's run method, depending on the platform. If it's Win2K or above, I'd go with the latter.
>>>
>>>Thanks, George.
>>
>>Anytime, Yuri. Since we're running Win2K and above, I do prefer the WScript.Shell. However, this also depends on the situation.
>>
>>For example, if the computer might need to re-boot with a script to run the setup, it's awfully tough to know whether or not the user selected the "Re-boot Now" option.
>
>George,
>
>They at MS recommend to use createprocess instead of winexec (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/winexec.asp). Do you have any opinion on this?

Yuri,

It depends. If you're trying to open a file, which may or may not have an application associated with it, then you'd want to use ShellExecute(). I've some programming in the download section (Run/Run With) that automatically handles this sort of situation. If there's no file association, then the "Open With" dialog appears.

If you're just trying to run an application, then CreateProcess() is the way to go. If memory serves, I think my late friend Ed Rauh, used it in his API_APPRUN class (also in the download section).