>I have a POS printer in COM1 port.
>I want to send control codes to it without using OLE or
>DOS commands. I read Ed Rauh article in KB about sending data to printer.
>I ran the following program according to this article.
>However, this sends incorrect data, probably baud rate is wrong. Print test
>page works correctly.
>
>Why? How to send control codes to COM1: port directly from VFP?

CopyFile() is not byte-oriented, and does nothing as far as setting the port parameters. It's also non-interactive, so it's not the right approach to the problem.

You have a few choices, none of which will be to your liking. The best solution is to use an ActiveX communications control such as the MSCOMM32 OCX, which gives complete control of the serial port via an ActiveX interface. There are samples here on UT of how MSCOMM can be used, VFPCOM allows you to (with effort) write event-driven comms with it, and I can guarentee that it works for exactly the type of application you want to write, since I use it to control barcode printers on COM ports. It is low-level port-oriented; there's no concept of file transfer protocols, or even of a file - it's byte streams and port conditions, just like you'd have to do to manipulate data streams at low-levels from other languages.

You can buy canned Comm products like CommTools; in general, the commerical offerings have higher-level concepts of serial manipulation available, and may offer .FLL or .DLL interfaces, probably with standard wrappers, to make life easier. If you don't want to learn the details of port manipulation, and want an easier model of development than is offered using something like MSCOMM, the money invested is probably worthwhile.

You can use the DOS MODE command to set the port characteristics and send stuff to the port using CopyFile() to send COMPLETE FILES to the port, or by setting up a generic/text-only printer on the port and using ??? to send an uninterpreted stream to the serial port. Neither mechanism gives you direct, programmatic control over the port states, or lets you interact with the port as a bidirectional device. You can embed whatever control codes you like in the file or ??? stream - the spooler won't step in and try to interpret the stream using the generic print driver.

You can write a device driver using a language with low-level manipulation capabilities and the appropriate plaform DDK. Been there, tried doing that. Markus Egger is right. Life's too short to spend time writing device drivers in C/C++ so that I can halfway duplicate functionality that's available elsewhere with better portability and less effort.

The old DOS-style low-level file I/O approach from FPDOS doesn't work in VFP, in large part because it isn't portable cross-platform.