I apologize, I thought you were using a serial port (RS232) communication. No, CommTools does not work with TCP.
Bruce
>Hey Bruce, sounds like a pretty good tool, but will it work with TCP? I barely know the difference between COM and TCP, but there is one, right?
>
>>Hi Jay,
>>
>>I have not done any comm programming since 2000. We used a library called CommTools. Looks like it is still available.
>>
>>
http://www.hallogram.com/commtool/>>
>>It worked very well for us. The documentation was decent and it had several FoxPro examples. Sorry I can't be more help. It's been too many years!
>>
>>Bruce
>>
>>>I know you're thinking, "Um, duh!" but...
>>>
>>>I'm opening a port for listening by using the following:
>>>
>>>
>>>.tcpServer.Object.LocalPort = m.Port
>>>.tcpServer.Object.Listen
>>>
>>>
>>>That port remains listening until... When?
>>>
>>>UPDATE: The real issue is that once something is sent from a 3rd-party app to the port, it doesn't seem to be able to send again.
>>>
>>>UPDATE2: This page had some possibly relevent, but I'm not sure if it really is:
http://www.netbook.cs.purdue.edu/othrpags/qanda148.htm>>>
>>>Primarily:
>>>
>>>A: That's unlikely. It's more likely that the application on B does not close (or shutdown) the socket after receiving the end-of-file. If your hypothesis was correct, side B would remain in the LAST ACK state instead.
>>>
>>>There is one other possibility: TCP has been implemented incorrectly. It could be that when a process is killed, TCP does not shutdown the control block correctly, meaning that it will fail to send an error message (RESET)