> The thing is that the code is in a dll, so application.processmessages
> might not work here. Or does it?

It depend on the caller of the DLL ! You may as well be called from a
thread. Calling the message pump from a DLL is risky when you don't know
anything about the calling process. If you have to write a DLL that works in
all (well most) cases, then you should probably put all your stuff into a
separate thread with his own message pump. The function exposed by the DLL
would create the thread suspended, pass all parameters, resume the thread
and wait until the thread terminate, then return to the caller. Within the
thread, you can do almost what you want, including calling the thread's own
message pump. You have to have a message pump or the ICS component will not
work within a thread. There are several samples with components running in a
thread.

--
[EMAIL PROTECTED]
http://www.overbyte.be


----- Original Message ----- 
From: "Markus Humm" <[EMAIL PROTECTED]>
To: "ICS support mailing" <twsocket@elists.org>
Sent: Sunday, May 01, 2005 3:56 PM
Subject: Re: [twsocket] ReadLine


> Francois PIETTE schrieb:
> > As expressed in the source code, ReadLine is deprecated. Anyway, it
doesn't
> > fit correctly with UDP protocol which is datagram oriented. Using
"lines"
> > with such protocol is strange.
> >
> >
> >>Now I have the problem that at one place in the program I need
> >>synchronus communication. I send out one byte and if I receive the same
> >>byte within some short timeout, I assume that the device I'm talking to
> >>has a echo mode.
> >
> >
> > Send your byte then program a loop waiting for the evnt OnDataAvailable
to
> > occur before a given time. Not the best practice, but that's how you can
> > implement synchronous operation if you really need this (you can ALWAYS
> > avoid synchronous operation).
> >
> > When you are in your wait loop, you must process events or your
application
> > will be locked. You must do something like that (not checked, out of my
> > head) :
> >
> >         FReceiveFlag := FALSE;
> >         WSocket1.Send(...your one byte data ....);
> >         while not FReceiveFlag do begin
> >             DummyHandle := INVALID_HANDLE_VALUE;
> >             MsgWaitForMultipleObjects(0, DummyHandle, FALSE, 1000,
> >                                       QS_ALLINPUT + QS_ALLEVENTS +
> >                                       QS_KEY + QS_MOUSE);
> >             Application.ProcessMessages;
> >             if Application.Terminated then
> >                 break;
> >         end;
> >
> > OnDataAvailable handler will set the FReceiveFlag variable to TRUE.
> > You can also use a TTimer to check for timeout.
> >
> Thanks for the reply, I will consider that tomorrow.
> Normally I do asynchronos communication, but for the first test wether
> my communication partner has echo or not I don't want this, I simply
> want this one synchronous.
>
> The thing is that the code is in a dll, so application.processmessages
> might not work here. Or does it? The timeout will be rather short anyhow
> (ca. 50 ms) and I think i do it with GetTickCount, which should be
> sufficient here and more easy to use than a at this place timer.
> Or is there anything bad with these ideas?
>
> Greetings
>
> Markus Humm
>
> -- 
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
>


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to