Thanks Ed. Yes, I did read the MSDN docs and used their example. RThreshold is effectively set at 1 char. But the first time OnComm() fire, I get the whole string from the Input property, not just one char. OnComm() will fire many times after than, with CommEvent = 2, but the Input property is empty.

If it were just that, I would be happy. The problem I'm having now, is that the OnComm() event doesn't fire sometime. I would get PC "A" sending a string many times to PC "B" and PC "B" OnComm() event won't fire at all. It's not constant, one time it doesn't work, I close all and restart the communication and then it will work (or the other way around). I have used your suggestion in another thread to use the VFPCOM.BindEvents(), it have improved things, but I'm still having some problems.

Is it the MSCOMM component that is buggy or is it VFP that doesn't work well with it? Why do we need VFPCOM.BindEvents() to make it work? Would I have the same problems if I redo the same component in VB?

TIA

>There are a number of events besides the receipt of a character that trigger the OnComm event; take a look at the OnComm Event example in the MSDN docs (yeah, they're in VB...but it's easy enough to figure out.) If the RThreshold set for the comm instance is one character, then it'll be triggered once per character received. If the port senses a change in the port being ready to send, it'll pop the OnComm event. The trick is to only respond to events that you've an interest in, and ignore everything else.