>>I must say, I think a Copy File was never used by us, and may cause additional problems. Think of two processes may need the printer (port etc.) at the same time. Try to be as native as possible, which in this case would be !Copy YourFile >PRN; this eliminates the VFP thread.

>Won't work for at least three reasons; first, COPY is an internal DOS command, so you'd be required to start another instance of the CLI explicitly, second, the target of COPY is not the STDOUT, so redirection via ">" is ineffective, and third, COPY will strip certain ASCII characters and terminate prematurely on receipt of some such as CHR(26) unless you tell it to operate in binary mode. If you wanted to shell out and use COPY, you need a different command line, ie:


>RUN COMMAND /C COPY /B YOURFILE PRN:
Since COPY is going to invoke CopyFile() IAC, you needlessly complicate the process, make error detection difficult, and pop a DOS box in the process.

>OBTW, WinNT and Win2K do not define the DOS Device PRN: by default; you have to do it yourself

Ed, I'm very sorry to put things wrong before (did it by heart, which I shouldn't). Instead of !Copy I should have said !Type. Thus, !Type YourFile >PRN (works on NT4 too).
A few things more :

The Dos-box of course you are right on, though we can get around this by some fuzzy API-thing (from MS KB), which doesn't work for NT yet.

Though technically this works, functionally it's nothing, since we depend here on the printer activated in Dos and which (for some network-OS - PC-OS combinations can't be done from within VFP). In the end our app now reads the ascii-file low-level and after a SET PRINTER TO PrinterName, line by line Say's it to the printer. This works fine.

Regards,