2Arno: >No problem to use async in a DLL, have a look at OverbyteIcsDll1 demo, >it shows a multi-thread capable implementation. If you don't need MT >have a look at the console demos, those with "con" in name, the same >princple works in a DLL as well. Thanks! I digged into OverbyteIcsDll1 demo and got a question. I see that in DLL demo the thread is responsible for message processing. But what if I don't need a thread? I tryed with while .. do MessagePump but noticed that it processes even the messages of the host app! So no sync here. I suspect console demo approach won't work for me too (am I right?)
2Francois: >If you need to export synchronous functions out of your DLL, I would suggest >using a thread >withing the DLL, having his own message ump and working purely >asynchronoulsy as ICS does so well. Then the exported function will talk to >this thread using traditional multithread synchonization mechanisms to looks >blocking from the outside. A Windows event is a perfect item for that kind >of job: the exported function will start the asynchonous operation by the >worker thread and wait on an event which will be set by the worker thread >once the work is done. Quite easy to implement without any change in TWSocket. Yeah, I guess it's the only way. I have to create separate thread or a socket would process host app events while waiting. I'll consider DoneFlag or even Events to easily implement waiting. >If you really want to do something like you have show, do NOT loop on >the state property value but use the events and your own application level >state variable. TWSocket.State has never been intended for waiting on a >given state. Hmm you mean State isn't reliable? But why? -- 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
