>I dug deeper into the dotnet version and discovered it was using winsock to communicate back and forth. They refer to the return communication as a 'callback' in documentation, but there isn't really a 'callback' method. It is simply using winsock to monitor the port and translate the data received.

Something similar was in the back of my mind when I suggested getting it working in pure dotnet first<g>

> I have a chat server/client I created in the past (long ago) using winsock so I can do that. The problem now is that the api sets up its own winsock connection and there is nothing listening once it is connected when accessed via com interop which is why I can send but not receive.
I am working with the developers at their end to see if they can add a method for me which will allow me to setup my own connection and pass the connection to the api so it will use it instead of creating one. Then I should be able to send and receive (in theory).

Having a working dotnet task it would have been easy to add a method yourself (assuming this dll was not sealed), but if the developers are made aware of such problems this also a good side effect.

>They have no other client/vendors using com interop so I am alone in this endeavor it appears (and why it takes so many versions of the com
>interop dll to get it right). In a few months it will be much simpler to work with their api using dotnet (it is written in dotnet), but until then it will be a pain in the arse.

Yupp, the level of interconnectedness needed in current apps is much higher than during the fpw/vfp change. Back then you could at least call back into the other OS with foxtools, and the inability of 64-bit applications to contact 32-bit COM is making me uncertain about the way to create future apps even if the client is still happy with vfp. But I have not really researched it yet.

regards

thomas