I see. I don't know about a 'better' mscomm but I do know it used to be a licenced subset of a more robust/documented product by Cresent Software. I believe there's a new company name or something for them nowdays. Sorry I can't offer more, good luck!

Steven-

>It's set at false which is default but it seems like setting it true would make matters worse. The mscomm needs
>total control when this transfer is happening. Nothing else is going on.
>
>>Hi Joe,
>> FWIW: I don't know if this is relevant to your situation but check out "Autoyield" in the VFP documentation. It helps keep VFP code and windows events discreet.
>>
>>Steven-
>>
>>>After much testing I think I can say that the mscomm oncomm event doesn't always fire when it is supposed to. I am
>>>implementing a nonstandard handshaking method. The control is a receiver. I have handshaking is turned off. RTS threshold is
>>>set to zero. I require 4800,e,7,2. Mscomm should wait for CTS to change to fire. Mscomm should sit and wait till string
>>>'q+chr(4)' is sent to it. As soon as the sender does that it should ping it's RTS line which it does and the receiver watches
>>>for CTS to change. Then the receiver sends it's ACK. MScomm never sees this CTS change half the time. I can't figure out
>>>why except that mscomm is not written well enough to handle this handshake method. Is there a better control somewhere
>>>that I can use?