Thanks Sylvain. That makes it a little clearer. So you are using a construct similar to a callback? You pass a reference to your VFP COM object and the method name and then when OnComm fires in your VB COM object you callback to the VFP COM object using the reference and name? Do I understand or am I way off here?

>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.