I've done something familiar with my VB project. I needed to connect to a scale via the serial port and I used MSComm for that. The application sent the command to the scale to return the current weight and the scale responded by sending the weight. My VB COM sent the command with MSComm.Output and received the weight in the OnComm event. VB would then send the weight to the application by calling a method of the object passed as a parameter to VB.

VFP doesn't play well with many ActiveX controls and MSComm is one of them in my book. I've got cases when couldn't get OnComm() events to fire at all. Like I said, VFPCOM.BindEvents() helped, by using VB is a far cleaner and efficient method IMHO.

VB doesn't need a wait state in that context. VFP will create the COM with NewObject() and the object will stay alive and will respond to events until it is killed by VFP. It act the same way has any COM created in VFP will do.

---

>Thanks for the response. I don't think VB would solve my problem. Maybe if I give you more information. My problem is that I want to issue a command from the serial port and wait for a reply. I initially thought I could send the command and loop until the OnComm event fired to change a state variable checked in loop condition. I think the problem is (and I think this is true in VB as well) that a wait state is needed to process the events that fire. That's why both VFP and VB have a doevents command. I think the OnComm is firing the number of times it should but VFP is not processing the event until the loop is exited. I think I've figured out a better way to do what I want using timers. I think the MSComm control works just fine in VFP if you use the OLE control container. How does VB process events? Does it need a wait state as well?