Posts: 1,956
Threads: 65
Joined: Jun 2003
Plasma,
We're not talking about DELTREE here. Were talking about COPY.
Regarding the /Y switch, I don't think you need it. I know that if the copy is done in a batchfile, then it ignores the existing destination file. I haven't tried the same thing on a copy from a Shell, but I suspect that the same holds true.
*****
Posts: 1,752
Threads: 21
Joined: Jun 2002
Moneo,
I know that. My point was that if DELTREE was translated, COPY probably is too.
Posts: 3,522
Threads: 189
Joined: Dec 2003
This file exist: C:\dummy
as well as this one: D:\Flupp
English:
SHELL "Copy D:\Flupp C:\dummy"
Do you wish to overwrite C:\dummy (Y/N/A)?_
Swedish:
SHELL "Copy D:\Flupp C:\dummy"
Vill du skriva över C:\dummy (J/N/A)?_
See the problem?
Just use $input(buffer), on any machine above, say 300mhz, you wont notice any difference.
Using shell might actually be slower since it: Opens a new shell, invokes copy, parameter cheks, copies, returns. Whereas $input(buffer): read the file, write to new file (copy).
Also, speed is not that big of a hazzle, a good line to follow would be: if an operation takes more than ~4-5sec display a loading message or rewrite the algo. if possible.
Moneo: Why go through the extra job of: writing a batch file (from within qb, using open, print) then shell batch. Where you as said before could just $input(buffer) the file?
Posts: 1,956
Threads: 65
Joined: Jun 2003
Quote:......
Swedish:
SHELL "Copy D:\Flupp C:\dummy"
Vill du skriva över C:\dummy (J/N/A)?_
See the problem?
(Moneo) Even if the destination file exists, this message will NOT appear in any language when the copy is not executed directly from the command-line, that is, when executed from a batchfile or from a Shell. So, there is no problem.
Using shell might actually be slower since it: Opens a new shell, invokes copy, parameter cheks, copies, returns. Whereas $input(buffer): read the file, write to new file (copy).
(Moneo) Yes, there is an overhead when doing a Shell. If the file is small, the overhead doesn't really matter. If the file is large, you will not notice the overhead at all.
Moneo: Why go through the extra job of: writing a batch file (from within qb, using open, print) then shell batch. Where you as said before could just $input(buffer) the file?
(Moneo) If you're only copying one file you can do a Shell. If you need to execute multiple copy commands, then you can put them into a generated batchflie if you want, and Shell to the batchfile.
Like I said in an earlier post, using a Copy to copy the files is much more reliable. Anytime you manipulate data there's always a chance that you might introduce an error. The Copy command is already there, why not just use it?
*****
Posts: 1,272
Threads: 36
Joined: Feb 2003
Why not use the copy command? Because:
1. Using the SHELL command pulls in all the needed support library code that makes the SHELL command work, which makes the EXE bigger than it needs to be.
2. Large programs, or ones that load a lot of data, won't have enough free memory for SHELL
But most importantly:
3. The copy command doesn't handle errors gracefully. It will attempt to print out a text-only error message even if it corrupts the display. With your own code, you're in control.
Also, as to concerns about corruption:
I write code to copy data between files using INPUT$ or things similar to INPUT$ all the time. Whenever it doesn't work, I always find the cause of the problem to have been between the chair and the computer.
I think I'll put together some speed & memory utilization benchmarks...
Posts: 1,956
Threads: 65
Joined: Jun 2003
Quote:Why not use the copy command? Because:
1. Using the SHELL command pulls in all the needed support library code that makes the SHELL command work, which makes the EXE bigger than it needs to be.
2. Large programs, or ones that load a lot of data, won't have enough free memory for SHELL
But most importantly:
3. The copy command doesn't handle errors gracefully. It will attempt to print out a text-only error message even if it corrupts the display. With your own code, you're in control.....
Sterling,
1) The increase in size in the EXE file is negligible. With the size of disks today, are we still concerned with a few K bytes?
2) This is true, but not normally a problem.
3) If you don't want to see the messages produced by Copy, redirect the output of the copy to NUL or to a file which you can examine for errors, where errors will by anything other than "1 file(s) copied."
*****
Posts: 1,752
Threads: 21
Joined: Jun 2002
What if the error messages are in a different language...?
Posts: 3,279
Threads: 170
Joined: Nov 2003
Quote:1) The increase in size in the EXE file is negligible. With the size of disks today, are we still concerned with a few K bytes?
The size of disks may be negligable, but there's a critical concept you are totally overlooking...
QB 4.5 generates 8088/8086 (not quite sure which) code. Executables operate within a 640KB memory space. That memory space, if SHELLed, has to have enough to spawn that child process. If it doesn't have the memory, it will simply fail. Those extra K are VERY valuable with our beloved little ancient compiler. Your argument here makes about as much sense as the newbie who whines about memory problems in QB and he says he has 512MB of RAM. 
I'd knock on wood, but my desk is particle board.
Posts: 1,956
Threads: 65
Joined: Jun 2003
Quote:...Your argument here makes about as much sense as the newbie who whines about memory problems in QB and he says he has 512MB of RAM.
My argument comes from 16 years of experience of writing countless production programs in QuickBasic. Your point and concern is possible, but highly improbable. I have been doing Shell in many programs and have yet to face the problem you state. My programs are generally in the range of 1000 to 2000 lines of code.
P.S. Don't get too personal when you disagree.
*****
|
