Hi Ed:
Actually I have no need of binding the Winsock control events to "local" code.
The DataArrival event of the Winsock control fires a method in my class passing the data arrived. The problem is that while the Winsock control is waiting for data everything falls in an "idle" state that is causing my COM dll to return right away to foxisapi.dll

I have used this class with the Winsock control in it many times and it works perfectly. When the class is included in a project that has a UI I have no problems since the UI will keep the program "alive" while the Winsock control is waiting for data. But inside a COM dll there is no UI and I can't use any event driven architecture.

Just to make things a bit clear here is the flow:

I create the class object.
The class calls the Winsock.Connect() method.
In the connect event of the Winsock control a signal the class to start sending data.
The class calls Winsock.SendData().
In the DataArrival event of the Winsock control I pass the arrived data to the class to be processed and send whatever data needs to be sent again.

As you can see there are two times when I need to "wait" for an event in the Winsock control. As soon as that "waiting" state starts the class returns right away to the place where I created it. This doesn't happen in a "local exe" since the UI will keep the class from going out of scope while waiting for the events.

Even if I bind the Winsock events to methods in the class, I still can't make it wait for the events to be triggered.


>>I downloaded VFPCOM but can't see the use of it to solve my problem.
>>The only thing I found that could be of use to me is the BindEvents() function, but as I understood from the docs it is used to bind an event in an automation server to a method on my class. The Winsock control is not an automation server (am I right?) and even if it was the problem would persist as the Winsock control would be idle while waiting for data.
>>
>
>No, an ActiveX control is an OLE Automation Server, and there may be events in the Winsock control that can't be wrapped directly with VFP code without the use of VFPCOM's BindEvents methods. You can create an instance of the Winsock object independent of a form. Unless there are events that are a part of the Winsock object that you want to wrap with VFP code, VFPCOM isn't going to do anything in particular for you. If there are events that are a part of the Winsock control that you wish to have trigger VFP code, you can construct the necessary wrapper from the ExportEvents skeleton class, and use that to create a VFP native object that is bound to an instance of the Winsock control by an instance of VFPCOM.
>
>>I'm about to give up on this one (something I'm not use to <g>).
>>These are the times when I really wish my customer was using Linux with Apache or anything else but NT/IIS. ;)