I would NOT recommend using direct API calls -- they're a real pain and generally inefficient (since in VFP you wouldn't have a means to set up callbacks, which usually means you have to resort to polling and "busy-wait" loops). Much of the code was adaptation of code (actually a rewrite, due to differences in Win16 and Win32 environments) that I'd originally written in FoxPro for Windows where didn't have option to use OCX control that encapsulated much of the functionality.
What I would suggest however is perhaps check to see if inserting a DOEVENTS in strategic locations helps. Places a DOEVENTS might help are just before you're reading status, or immediately before trying to read data, or just after call that sends data. As with what happened in my code, the DOEVENTS would get the FoxPro p-engine to give up the remainder of its timeslice, thus giving more CPU cycles for other processes (in particular any code servicing the network communications).

>thanks for your feedback, i' will try with api calls...
>
>>>Hi all, I got into this problem.
>>>I need to send three bytes to a sort of trafficlight (ie : chr(160) + chr(5) + chr(1) ). The problem is that the receiver does not react as i expect. Looks like it does not buffer info so that i loose many packets. I tested wih a java program and in this case it worked fine.
>>>My question is, is there any settings I can make ? Maybe wnsock is sending something i don't know ? As you can see i'm not expert at all in those things :)
>>>
>>>thank you
>>
>>Probably won't help much in your case, as what code I've got using winsock uses TCP and calls the API functions directly (rather than using the OCX control). Ran into peculiar problem where data seemed to get 'stuck" somewhere in some situations -- and addition of debugging code to step through the process, or running through a debugger would solve the problem. Then it dawned on me -- this looked just like the problem I'd run into when communicating over the serial port (again using API calls rather than OCX) -- in particular when a USB-to-serial "dongle", USB modem, or a "WinModem" (i.e. one that doesn't actually have a UART). Found that I periodically need to do a DOEVENTS (typically where an "idle loop") to make sure that these devices are being serviced -- essentially by calling DOEVENTS you're freeing up the current "timeslice" and allowing other programs to run.