Need execute DOS command and WAIT 2

[johncook]

Obviously this has bee asked so many ways and I have read a bunch of the postings.

First someone please clear this up:

I am attempting to run PCAnywhere from the command line. It works perfect as long as I do not mind my VFE code running the program but NOT waiting on PcAnywhere to complete before continuing to the next command in my method.

In other words with RUN /N1 everything works perfect except the next line gets executed BEFORE PcAnywhere completes it's task.

The same exact command does not work at all if I do not pass the /N1.

I have converted all the long pathnames to XXXXXX~1 so there were no spaces in the command line and without the /N still no success.

Obviously you can not use the RUN command to run a dos command and wait.

So, the question is how do I accomplsih this? I have read a lot of postings about using some VisuallBasic stuff, but I have no Visual Basic stuff and know nothing about VB.

Anybody have options?
Thanks,
John

 

[jimoo]

You can try setting vfp autoyield to false. Running your command, and later setting it back to .t.

_vfp.autoyield = .F.

If that does not work.

You can create a file.
STRTOTEXT('myTempFile',"Hello&quot
Run your command
DO WHILE .t.
* may wish to include a timeout so it doesn't get stuck
* in a loop if something fails.
IF FILE('mytempfile.txt')
WAIT "" timeout 1.0
ENDIF
ENDDO
DELETE myTempFile.Txt


Here is the _vfp.autoyield information:
Specifies whether an instance of Visual FoxPro processes pending Windows events between execution of each line of user program code.

ApplicationObject.AutoYield[ = lExpr]
Property Values
lExpr
Specifies whether an instance of Visual FoxPro processes Windows events between each line of user program code. lExpr can be one of the following logical values: lExpr Description
True (.T.) (Default) The instance of Visual FoxPro processes pending Windows events between execution of each line of user program code.
If lExpr is set to true (.T.), the instance of Visual FoxPro processes pending Windows events in the same manner as earlier versions of Visual FoxPro.

False (.F.) The instance of Visual FoxPro does not process pending Windows events between each line of user program code.
All pending Windows events are placed in a queue, and the events in the queue are processed when DOEVENTS is issued or a wait state occurs. A wait state occurs when Visual FoxPro is waiting for input from the user. The WAIT command does not create a wait state



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[jimoo]

The more I think about it I am not sure if the loop will work. Stick with the autoyield for now.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[johncook]

Hi Jim,
Well I tried the autoyield but no success.

You know if I try this line of code without the /N1 I see the DOS command window flash. Nothing happens, i.e. PcAnywhere does not get executed bu the fact that the DOS window flashes tells me that RUN is trying to do something.

The command line is:
lccommandline=<path and name of pcanywhere runtime.exe> plus a space and then <path and name of file for pcanywhere to run>
RUN /N1 (or no /N1) &lccommandline

I an using all the directory short names so there are no spaces in either parameter's value.

I am wondering if the space between the two parameters is what causes the problem when I do not use the /N1

I am going to put the command line in a dos batch file and try that.

John

 

[longda]

John I have had the same problem in past. I have found a very simple solution that works very well if I have to run other exe's and wait for them to finish before the next line of code runs.

I use the FOPEN() function with the first parameter being the path and file name of the exe and the second parameter is 2. If you use the nuber 2 as the second parameter VFP will try to open the file in the first parameter as Read\Write Buffered. If you are currently running the exe then there is no way the FOPEN function will be able to open that exe file. So you can put this in a loop to see when you get a file handle then you know the exe is finished and you can continue with your own code.

Here is an example:
* Run the exe file
RUN /N7 c:\test.exe

* Loop until the exe is done running.
DO WHILE .T.

* Try to open the exe file in low level.
l_nFile=FOPEN(&quot;c:\test.exe&quot;, 2)

* If l_nFile is anything other than a negative 1
* then that means we were able to get a correct
* handle to the file, and that means the exe is
* no longer running.
IF l_nFile <> -1

* Now since we did in fact open the file we must
* close it and exit the loop to continue with our
* program.
FCLOSE(l_nFile)
EXIT
ENDIF
ENDDO
* Continue your code here.

Hope this helps you out.

Thanks,
Dave Long

 

[wgcs]

A less-simple solution:

http://fox.wikis.com/wc.dll?Wiki~ProcessExitCode

thread184-620372

 

[ramani]

Hi John


loShell = CREATEOBJECT(&quot;wscript.shell&quot
lnSuccess = loShell.Run(myDosBatchCmd,1,.t.)

This will wait for the execution of myDosBatchCmd



ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[johncook]

Thanks All,

I never realized this subject is one that has been a source of confusion for sooooo long.

I must have read 100 postings on this board and the UT.

As usual with FoxPro there is about a 1000 ways to do anything. What amazes me is that you can find solutions where there are 100's of lines of code involved to solutions involving 2 lines of code.

I found a solution very similar to the one posted by Ramani.

Here it is so that it helps someone else in the future:
Also, here are some key words to help someone looking for a solution: RUN /N DOS COMMAND WAIT

lctempstr1=(CHR(34)+ALLTRIM(This.oapplication.osyssetup.mlocpcanyw)+CHR(34)+&quot; &quot;+CHR(34)+ALLTRIM(This.oapplication.osyssetup.mwhtxfrpgm)+CHR(34))
oShellobj = CREATEOBJECT('WScript.Shell')
oShellobj.Run('&lctempstr1', 1, .T.)

Explanation: I did nothing special to make use of the above code. I mean by that I did not have to find or ensure I have something named WScript.Shell. I guess it just exists. I am using VFP 7.0 on Win XP Pro. My application includes software and hardware so I am in a pretty controlled environment. I have no idea if this works on other versions of FoxPro or Windows.

In case the This.oapplication.osyssetup.<property name> are confusing, I have a table called syssetup which contains system configuration settings (things about how the app runs in this particular facility). At the beginning of my app I take all the values from this table and load them into a property of the app. That way they are available throughout the app.

If I have any warnings it would be to tell you to be sure you make oShellobj a variable that gets released. I did read where people had problems being able to run this once but not again until they rebooted the computer. I suspect that may have been why but do not know this for sure.

My example is using this code to execute a PCAnywhere file transfer from inside a click method of a button on a form. The PCAnywhere execution calls for running the PCAnywhere program (parameter #1 in the value built into lctempstr1) and what transfer program to run (parameter #2 in lctempstr1).

When I was attempting to use the RUN command I had a lot of problems where you could get this to work with the /N but not without it. Of course with the /N you get it to run but can not get VFP to wait until it has completed execution. I had a lot of problems with path names such as Program Files where there was a space in the directory name. I tried Progra~1 which worked somewhat but still no ability to &quot;wait&quot;.

With the above solution I use the Program Files (long) directory name and everything works perfectly.

I hope this helps as this is obviously a subject on which a lot of time and resources have been expended.
John

 

[longda]

Yeh ramani that is a pretty good solution. I am definitely going to find that helpful in the future, and because of that I gave you a star. I learn something new from this site everyday.

Later,
Dave Long

 

[wgcs]

FYI, since it isn't obvious from the posts here:
Not every computer has WSH (Windows Scripting Host) installed: It is an optional component availble only in some Windows OS versions:

http://fox.wikis.com/wc.dll?Wiki~WindowsScriptingHost

Plus, many system administrators have disabled WSH because it enables many of the internet worm/viruses to spread, and it is rarely used in commercial applications.

So, if you use this method, you'll have to ensure that WSH is installed for it to work.