Re: run command
- From: "Dan Freeman" <spam@xxxxxxxxxxxxx>
- Date: Sat, 10 Mar 2007 14:42:05 -0800
They only move data into a memory variable if you tell them to move that
data to a memory variable.
If you don't use a memory variable, they'll move a LOT more data than a
memory variable can hold.
I actually have code running at clients where using memory variables failed
(because of size), but straight pass-thru works just fine.
Dan
"Cy Welch" <cywelch@xxxxxxxxx> wrote in message
news:%23l4hksrYHHA.4616@xxxxxxxxxxxxxxxxxxxxxxx
Unless I am misunderstanding those commands, filetostr copies a file to a
memory variable and strtofile copies a memory variable to a file.
Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com
Dan Freeman wrote:
The limit is 16MB, I think.
But remember that's a limit on *memory variables* and the command I
posted doesn't retrieve data to memory variables. <g>
Dan
"cj" <cj@xxxxxxxxxxxxx> wrote in message
news:Oa7%23Y5fYHHA.3996@xxxxxxxxxxxxxxxxxxxxxxx
Yea but I hate it when something that should work doesn't and I can't
figure out why. That might work. Is there a limit on string length? I
mean I know system resources limit everything but I mean a certain
number of chars?
Dan Freeman wrote:
You've already spent way more time on this than it should take. :-(
If something like this doesn't work for you:
StrToFile( Filetostr(lcHeaderFile) + Filetostr(lcDataFile),
lcOutputFile)
then just write a .BAT file and execute *that*. With a .BAT file you
could even use ECHO and PAUSE as part of the process.
Dan
"cj" <cj@xxxxxxxxxxxxx> wrote in message
news:OKs$P8cYHHA.984@xxxxxxxxxxxxxxxxxxxxxxx
I'm sorry I don't really understand what your saying. Here's what I
have to do.
I have a directory full of delimited data files to process. I scan
through all the records after importing them into a table. After each
data file is processed they need to be moved to another directory for
backup/storage/proof of what we got. Problem: The owner wants a
header record put on these data files. I thought I could copy a text
file with only the header record in it + the data file to the backup
directory and then delete the original file. Works in DOS. Can't get
it to work using the run command from VFP. Can't understand why not.
It appears but I'm not sure that it has to do with the fact that these
file names and or directories can have spaces in them and are quite
long. In DOS I put ""s around each file name but again it doesn't
work in Run from VFP.
Idea #2 inspired from your message. I use strtofile to write the
header out to the processed directory then copy all the records to
that file. Bummer, copy to seems to overwrite the file which gets rid
of my header. I've asked another question here to see if I can fix
this.
Idea #3 If the above doesn't work I'll start by appending a blank
record to the DB that the data files are read into. I'll then bring
in the data files. Next I'll goto record 2 then scan through the file
doing the processing. Last I'll copy all records to the backup file.
Maybe that's best.
101 ways to do it and it's taking me forever to figure out which is
best. Plus I hate it when something doesn't work and I can't figure
out why but if I waste another day on this folks are going to get
ticked.
Jan Bucek wrote:
I suggest to abandon old RUN command and use Wscript.Shell for
example. This way you gain more control, see my test code:
******** TEST ************
clear
local lcA, lcB, lcC
lcA=FullPath([file a.txt])
lcB=FullPath([file B.txt])
lcC=FullPath([file C.txt])
StrToFile("this is file A", lcA)
StrToFile("this is file B", lcB)
erase (lcC)
mCmd=[cmd /C COPY "]+lcA+[" + "]+lcB+[" "]+lcC+["]
? mCmd
oWS=CreateObject("wscript.shell")
oWS.run(mCmd, 4, .T.)
********** ENDTEST ************
WScript.shell description:
details in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/6f28899c-d653-4555-8a59-49640b0e32ea.asp
object.Run(strCommand, [intWindowStyle], [bWaitOnReturn])
Arguments
object WshShell object.
strCommand
String value indicating the command line you want to run. You must
include any parameters you want to pass to the executable file.
intWindowStyle
Optional. Integer value indicating the appearance of the program's
window. Note that not all programs make use of this information.
bWaitOnReturn
Optional. Boolean value indicating whether the script should wait for
the program to finish executing before continuing to the next
statement in your script. If set to true, script execution halts
until the program finishes, and Run returns any error code returned
by the program. If set to false (the default), the Run method returns
immediately after starting the program, automatically returning 0
(not to be interpreted as an error code).
Remarks
The Run method returns an integer. The Run method starts a program
running in a new Windows process. You can have your script wait for
the program to finish execution before continuing. This allows you to
run scripts and programs synchronously. Environment variables within
the argument strCommand are automatically expanded. If a file type
has been properly registered to a particular program, calling run on
a file of that type executes the program. For example, if Word is
installed on your computer system, calling Run on a *.doc file starts
Word and loads the document. The following table lists the available
settings for intWindowStyle.
intWindowStyle Description
0 Hides the window and activates another window.
1 Activates and displays a window. If the window is minimized or
maximized, the system restores it to its original size and position.
An application should specify this flag when displaying the window
for the first time.
2 Activates the window and displays it as a minimized window.
3 Activates the window and displays it as a maximized window.
4 Displays a window in its most recent size and position. The active
window remains active.
5 Activates the window and displays it in its current size and
position.
6 Minimizes the specified window and activates the next top-level
window in the Z order.
7 Displays the window as a minimized window. The active window
remains active.
8 Displays the window in its current state. The active window remains
active.
9 Activates and displays the window. If the window is minimized or
maximized, the system restores it to its original size and position.
An application should specify this flag when restoring a minimized
window.
10 Sets the show-state based on the state of the program that started
the application
cj napsal(a):
I did this
dimension inbarray[2]
inbarray[1]="cj.txt"
inbarray[2]="cj2.txt"
mfname='"c:\test\from dir\'+inbarray[i,1]+'"'
mtargname='"c:\test\from dir\to dir\'+inbarray[i,1]+'"'
mcmd='cmd /K copy "c:\test\headerfile.txt" + ' + mfname + ' ' +
mtargname
MESSAGEBOX(mcmd)
run &mcmd
The cj.txt was copied and the DOS window remained open. I typed
exit in the DOS window to allow the FoxPro program to continue.
cj2.txt flashed open a DOS windows but it didn't remain open and the
file was not copied. ??????
Jan Bucek wrote:
use "cmd /C COPY ..... " in your string
or
"cmd /K COPY ... " to force the command window to wait and show the
results
cj napsal(a):
This command works fine from the dos prompt
copy "c:\test\headerfile.txt" + "c:\test\from dir\cj.txt"
"c:\test\from dir\to dir\cj.txt"
Why doesn't this work in VFP 8?
dimension inbarray[2]
inbarray[1]="cj.txt"
inbarray[2]="cj2.txt"
mfname='"c:\test\from dir\'+inbarray[i,1]+'"'
mtargname='"c:\test\from dir\to dir\'+inbarray[i,1]+'"'
mcmd='copy "c:\test\headerfile.txt" + ' + mfname + ' ' +
mtargname
MESSAGEBOX(mcmd)
run &mcmd
The dos screen goes so quick I can't see what it says if anything.
So, I then tried this.
mcmd ='pause'
run &mcmd
It works. Dos window opens with
C:\test>pause
Press any key to continue . . .
.
- References:
- run command
- From: cj
- Re: run command
- From: Jan Bucek
- Re: run command
- From: cj
- Re: run command
- From: Jan Bucek
- Re: run command
- From: cj
- Re: run command
- From: Dan Freeman
- Re: run command
- From: cj
- Re: run command
- From: Dan Freeman
- Re: run command
- From: Cy Welch
- run command
- Prev by Date: Re: quickly get new lines... strange GRID behaviuor
- Next by Date: Re: Command Window
- Previous by thread: Re: run command
- Next by thread: Visual Foxpro MSCOMM & Barcode Reader
- Index(es):
Relevant Pages
|