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?)
If you don't created a thread with his own message pump, then you rely on
the host application which may or may not have a message pump and may do
stranges things with his message handling. You get the best isolation from
the host application by creating a worker thread and run most of your code
in the context of this thread.
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?
State is reliable, but only from the event handlers, not at anytime as seen
from the outside. This is how Windows event handling is working: the state
variable is updated inside an event hanlder and that event handler may
execute code before exiting. The safer way to access the state variable is a
the point where the component user is at control: during the event handlers
he has installed.
Antoher way to consider this is that you have two asynchronous processes
(Those are not processes in the sense they are defined within Windows):
TWSocket code and your own code. The link between the two process have been
designed to work at specific spot in time : when the component triggers an
event.
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
--
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
--
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
