So if I open up a command prompt and enter the following command:

echo this is a test > com1

is this going through my print driver? How about this one:

copy file test.txt com1

These commands don't care if there is a printer driver attached. They work fine, and I don't think they are going through the print driver or the print spooler. I could certainly be wrong. It seems to me that the print driver attaches itself to the port, but doesn't open it until it needs to print. If open the port with mscomm and then change the print driver to use com1 there is no problem with the operation, but it will error when I try to print something using the print driver. That job will hang in the queue in an error state until I close the port with the mscomm control.

It seems to me that the printer driver is happy to let something else use port when it is not printing, but that mscomm will not open the port unless it can have exclusive access to it. If this is the case, is there some other tools I can use to work with the port that might work better?


>
>Agreed, from the command line - but not with the MSCOMM control. In this case the driver is doing exactly what it should - printing.
>
>
>I agree with all the above, except the MSCOMM.OCX does not require exclusive access - it will take it once it opens the port, just as the generic driver. That Portmon that I pointed out to Bill plays nicely, as it allows another app to join in. Moving the printer driver to another port just opens things up for the control. First one in wins.