It's the only way I've found to make the MSComm object to work. I send a string and I wait for a confirmation in a DO WHILE loop. If I don't put a DOEVENTS in the loop, VFP will miss the confirmation in the input buffer of the modem. Naturally, the DOEVENTS prevents me from compiling the COM in a DLL. I must compile it as a EXE.

At this point, I'm very disapointed in the way the object work. It crashes when it exit and now I have a computer that won't even recognize that it have something in the input buffer. If it act like a server and calling another PC it work, but it won't act like a client.

I am strongly tempted to rewrite the COM in VB, to see if it's VFP that doesn't play nice (why the hell does it need VFPCOM.BindEvents() to work?) or the MSComm object. The problem is that I'm getting late in the project and I would like to salvage the existing COM if possible.

>Why do you have a DOEVENTS in a COM server?