🚀 go-pugleaf

"Lesley Anne" <mspfila-ng@yahoo.com> wrote in message
news:44f73d33$1@newsgroups.borland.com...

> I'd like to use that method, but it only seems to take care of the
> TIdPeerThread cases.  Since OnListenException takes place
> in the context of a TIdListenerThread instead, would it not work
> there?

There is nothing you can do about manipulating those threads.  You will have
to use the TIdSync approach for that event instead.  TIdSync has a secondary
constructor that does have a thread parameter.  That constructor creates a
thread internal to the IdSync unit and is then used that for the call to
Synchronize().

Otherwise, re-design your code to not require Synchronized methods in the
first place.  For instance, if all you are trying to do is log the error
messages, then write your logging code to be thread-safe, such as protecting
the log file with a critical section, and don't access the UI directly at
all.  If you must use the GUI in your logging, then have the logging code
post strings to a thread-safe queue that the main thread can then display
perioically.

> In your TIdSync descendant, I kind of got lost on what ended up
> happening to the string.

It gets stored into the FStr member of the class, then TIdSync::Sychronize()
calls TThread::Synchronize(DoSynchronize) internally, and then
TMySync::DoSynchronize() uses FStr as needed.

At some point it needs to reach my form where I can display it.

That is what the overriden DoSynchronize() method is for.

> So would that go with something like:

Yes.

> Basically, will Sync->Synchronize() take care of whatever it needs
> to do to make sure the threads actually are in synch, then call my
> DoSynchronize() function in a context where it's safe to do so?

Yes.

> Part of my problem in understanding this is that I don't really
> understand quite what Synchronize() does in the first place.

See above.


Gambit