>I have an existing DLL that was written to use TClientSocket via a data >module. It has a kind of message pump but it works in reverse... it has a >timer thread that uses postmessage to trigger the main app to call a >ReadData function which checks the socket for received data, then processes it. It's a really overcomplicated one! I'd recommend you to isolate main app objects/variables from DLL ones as strongly as possible. For example:
* Main app calls DLL's Connect() with a pointer to callback method. * DLL's Connect() saves this pointer, allocates buffer for data and connects to the host specified * In OnDataAvailable DLL copies data to buffer and calls the callback with parameters (PBufStart: PByte; PDataLen: Integer). * Callback copies data to application's buffer thread-safely (you'll have to use additional thread for socket messages otherwise you'll get funny side effect when DLL's Socket.MessageLoop processes main app's messages) and signals main app thread to process the data received. Callback should return number of bytes it has read so that DLL could move a pointer to data start in the buffer. In general, only simple and cross-language types should be used when interacting with DLL. This means NO CLASSES in parameters/results! -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
