Problems with RUN/! command

[CFB]

For some reason the RUN command isn't running the specified application. Can anyone see any flaws in my code?

cDB = "FOR"
cTFile = "c:\test\file.t"
cXFile = "C:\Program Files\myapp.exe"
cProgPath = cXFile + " -q -r " + cTFile + " " + cDB + " LIVE"
run &cProgPath

The command window closes immediately after it opens. I used the same cProgPath string to run the program from a DOS prompt and through a VB application using the Shell() function and had no problems. Thanks for the help.

 

[chpicker]

Try using this line instead:

run /n &cProgPath

While I can't find any flaw in your code logic, the "/n" parameter runs the line and allows FoxPro to continue on immediately after. However, it also seems to have the side effect of not closing the MS-DOS window afterward, leaving it open to see whatever error message you might be getting from your command line.

The "proper" way to do this, of course, is to edit the FoxRun.pif file in your main VFP directory and uncheck the "Close on exit" box.

 

[CFB]

I actually don't want FoxPro to continue with the next line of code until the program that's been executed with the RUN command has finished. Could the problem be the way I'm trying to use a MS-DOS command that passes parameters along with the exe path? I'm stumped on this...

 

[nl]

Are you using VFP 6.0? Which service pack do you using?

Probably it does not support long file name.
Try to using [c:\Prog~1] instead of [c:\Program files]

 

[jworley]

Hi, I have just had this problem myself ...

The ! command doesn't seem to support parameters specified after the .exe filename for some reason (VFP6). This happened to me when I tried to run the Windows/DOS FTP program like this:

run /n c:\windows\ftp.exe -s:c:\myapp\ftpscript.tmp

This just ran the FTP program without parameters resulting in an immediate exit / DOS window close, when it should have run the FTP script I was trying to point it to.

The best way I found was to create a batch file enclosing the entire command string, create a .pif file for that batch file, put this in the /windows directory and hey presto no problem.

So, run /n c:\progdir\doftp.bat worked fine - all except for the fact that after the batch file terminates, it leaves my VFP app in a minimised state. See my other post !! Jim Worley
jim@aits-uk.net

http://www.aits-uk.net

 

[dgrewe]

chpicker mentioned "/n", remember to replace the n with a number between 0-7. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[ChrisCarroll]

I disagree.
The problem is indeed the long file name, specifically the space in c:\Program File\myapp.exe. It means that DOS parses this as asking for a program called "c:\Program" which isn't there, hence the DOS window closes instantly. It's not a FoxPro problem at all.

It should be solved by adding a pair of single quotes or square brackets, so that DOS gets passed the quotes around the exe path, which is how DOS can deal with pathnames that include spaces.

cXFile = ["C:\Program Files\myapp.exe"]

The Run command does allow parameters to passed along to DOS, so Jim's problem must have been caused by something else.

 

[ChrisRChamberlain]

CFB

I actually don't want FoxPro to continue with the next line of code until the program that's been executed with the RUN command has finished.

This is easily acheived with a WinAPI call as opposed to using the RUN command - will post such code if you are unable to find anything suitable.

Chris

 

[CFB]

I actually tried using WinAPI calls. I created a handle to the open application using the WinAPI function OpenProcess(), then I used the WaitForSingleObject function to wait for the the executable that I ran to finish. I also tried GetExitProcessCode. Unfortunately, both of these functions caused my the application I run to crawl. The front end I'm working on was supposed to be a quick and dirty project, so I didn't spend a lot of time troubleshooting what the problem was. I read a few boards where other people were experiencing the same problem. Anyone else had this problem?

I tried using this sample piece of code to execute Visio and got the same result where the Command window opens and closes immediately.

local cApp
cApp = ["C:\progam files\Visio\Visio32.exe"]
run &cApp

I also tried:

local cApp
cApp = [c:\Prog~1\Visio\Visio32.exe]
run &cApp

I tried different variations of cApp to include quotes, not include quotes, with and without brackets, etc. Has anyone tested this on their machine and got it to work? Thanks again for all the help everyone.

 

[CFB]

I got it working I think, I used
run [c:\progra~1\visio\visio32.exe]

I should have looked at the MS-DOS name for the Program Files directory in the first place. Thanks again everyone. If people have experienced problems using the Win32 API functions WaitForSingleObject() and GetExitProcessCode(), I'd love to hear about them and if you were able to, how you resolved them. Thanks again.

 

[dgrewe]

http://ibs.internationalbid.net/home/dave/code_html/isfileinreg.html

Maybe this will help you with the run command and give you some Ideas for the wait,

To not use the run command try

http://ibs.internationalbid.net/home/dave/code_html/runexe.html

sample code

ccWebExe = IsFileInReg("WebDrive.exe&quot
* ccWebDrive = C:\program Files\riverfront\webdrive\webdrive.exe"
...... code.....

if ftpon(alltrim(CUSTOMER.FTP_NAME)) = .f.
... error code
endif
...code...

procedure FTPON
paramter pcFtpSite
lcRunApp = ' start /wait "' + ccWebExe + '" "' + pcFtpSite + '"'
lcCheckFile = alltrim(SYS_PARA.FTPDRIVE) + alltrim(SYS_PARA.FTPDIR) + alltrim(SYS_PARA.FTPCHKFILE)
lnAttempts = 10
*
for lnX = 1 to lnAttempts
run /n2 &lcRunApp
wait "Waiting for Connect to " + pcFtpSite window timeout 5
for lnY = 1 to lnAttempts
on error do errortrap
gnError = 0
* does the prepositioned default file exist.
if file(lcCheckFile)
exit
else
wait "Connect Failure " + pcFtpSite + chr(13) + "Attempt " + alltrim(str(lnY)) window timeout 5
endif
endfor
*
if lnY < lnAttempts
exit
endif
*
endfor
*
return lnX < lnAttempts David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[ChrisRChamberlain]

CFB

The following code has been lifted from an application, so you would need to change the value of lcProgram and ON ERROR DO ...

lcProgram = ALLT(USER.editor);
[tab]+[ &quot;];
[tab]+ALLT(GALLERY.path);
[tab]+ALLT(GALLERY.filename);
[tab]+[&quot;]

#DEFINE NORMAL_PRIORITY_CLASS 32
#DEFINE IDLE_PRIORITY_CLASS 64
#DEFINE HIGH_PRIORITY_CLASS 128
#DEFINE REALTIME_PRIORITY_CLASS 1600
#DEFINE WAIT_TIMEOUT 0x00000102
#DEFINE WAIT_INTERVAL 200

DECLARE INTEGER CreateProcess IN kernel32.DLL;
[tab]INTEGER lpApplicationName,;
[tab]STRING lpCommandLine,;
[tab]INTEGER lpProcessAttributes,;
[tab]INTEGER lpThreadAttributes,;
[tab]INTEGER bInheritHandles,;
[tab]INTEGER dwCreationFlags,;
[tab]INTEGER lpEnvironment,;
[tab]INTEGER lpCurrentDirectory,;
[tab]STRING @lpStartupInfo,;
[tab]STRING @lpProcessInformation

DECLARE INTEGER WaitForSingleObject IN kernel32.DLL ;
[tab]INTEGER hHandle,;
[tab]INTEGER dwMilliseconds

DECLARE INTEGER CloseHandle IN kernel32.DLL;
[tab]INTEGER hObject

DECLARE INTEGER GetLastError IN kernel32.DLL

start = long2str(68) + REPLICATE(CHR(0), 64)
process_info = REPLICATE(CHR(0), 16)

File2Run = (lcProgram) + CHR(0)
RetCode = CreateProcess(0, File2Run, 0, 0, 1, ;
NORMAL_PRIORITY_CLASS, 0, 0, @start, @process_info)

IF RetCode = 0
[tab]=MESSAGEBOX(&quot;Error occurred. Error code: &quot;,
[tab]GetLastError())
[tab]RETURN
ENDIF

hProcess = str2long(SUBSTR(process_info, 1, 4))

DO WHILE .T.
[tab]IF WaitForSingleObject(hProcess, WAIT_INTERVAL) != WAIT_TIMEOUT
[tab][tab]EXIT
[tab]ELSE
[tab][tab]DOEVENTS
[tab]ENDIF
ENDDO

RetCode = CloseHandle(hProcess)

ON ERROR DO ErrorTrap WITH;
[tab]SYS(16),;
[tab]LINENO(),;
[tab]ERROR(),;
[tab]MESSAGE(1),;
[tab]MESSAGE()

Chris

 

[CFB]

Ok, the long file path was definitely the problem, my application is running fine. Now though it seems the the Command Window is closing before my application has finished executing. Off to do more testing...

 

[ChrisCarroll]

Do you mind if I ask - since the subject has come up - what's the reason for considering using WinAPI to run a program?

My experience with FoxPro Run has been, that if use:

!App.exe param1 param2

then the App runs and FoxPro waits for it App to finish; and if I use,

!/n App.exe param1 param2

then FoxPro doesn't wait. Either way, the picks up the parameters.

That seems to cover everything we might want. So what has you reaching for WinAPI calls?

Thanks,

Chris

 

[CFB]

The reason I was using WinAPI calls was that I had created this small front end in VB. The Shell() function in VB doesn't wait for the executable you run to finish before proceding the next line. Normally I use the GetExitProcessCode and WaitSingleObject functions are normally used to manage that. This was supposed to be a quick project, so I decided to create a VFP form since I knew the RUN/! command waited for the exe to finish executing before proceeding to the next line of code. My problem now is that I'm executing the code with the RUN command, but the Command Window seems to close immediately and VFP continues with the next line of code. Anyhow, that's why we were discussing WinAPI calls.

 

[jonscott8]

Hi Chris,

I'll see if I can adequately explain this. The reason many are quick to suggest using the WinAPI (especially for creating new processes) is because of the amount of additional functionality that it provides.

Using the argument of this thread (VFP's RUN command vs. WinAPI CreateProcess function), the RUN command is simply a high-level interface to the CreateProcess function. Hence, it doesnt expose all the available functionality as if you were to use the CreateProcess function directly.

For Instance, using the RUN command, you cannot specify how the window of the new process is displayed (maximized,normal,hidden), w/o getting into .PIF file usage. You also can not set the working directory of the new process, but you could using CreateProcess.

My rule of thumb, is to only delve into the WinAPI when I need functionality not exposed by the development tool I'm using. Jon Hawkins

 

[ChrisRChamberlain]

For Instance, using the RUN command, you cannot specify how the window of the new process is displayed (maximized,normal,hidden).

Just to expand on Jon's explanation, the hidden option can be important where you do not want the user to have access to another Windows application.

An example would be where a command line version of PkZip or similar would be zipping/unzipping files in parallel with the VFP application.

With the RUN command, users are able to access and even terminate the mimimised application. Also DOS icons look somewhat out of place on today's taskbars, as do the contents of a DOS box.

With a WinAPI call, the application can run maximised, normal, minimised or hidden - the only way to detect and/or interfere with a hidden application is through the use of CTRL+ALT+DEL.

Thus, depending on the requirements, a WinAPI call can give you a more robust solution than the RUN command.

(An example WinAPI call can be seen at FAQ184-145)

Chris