"John Carlyle-Clarke" <jpcc@removethis.bigfoot.com> wrote in message
news:Xns97C0B19B5FC74discombobulation@207.105.83.66...
> The context.data has a class of my own which has the hwnd of the
> form, so when ReadLn returns in the Execute event I get the window
> handle from context.data and send a message to it to display the text.
Keep in mind that the VCL may recreating its HWNDs at any time, so you
should consider having your form override its CreateWnd() and DestroyWnd()
methods so you can detect when the HWND is destroyed/recreated in order to
update your contexts accordingly.
> What I can't work out is how to respond to the user pressing the
> "Send" button on my connection form, to send text back to the remote
> unit.
Your form already has a pointer to the particular Context that you need to
send your data to. So simply use the Context's Connection property as
needed. However, if the server needs to send data to the same client at the
same time, then you need to implement your own locking mechanism, such as
with a critical section, to ensure that the two threads do not step over
each other's data.
> I can't just call context.connection.IOHandler.write in the
> button event, because that would block the GUI.
As it should be. If you don't want the blockage, and the GUI doesn't need to
wait for the data to be sent, then you can add an outgoing buffer to your
Context, such as with a TMemoryStream, that the button writes to, and then
have the server's OnExecute event check the buffer for pending data and send
it when appropriate. Again, make sure access to the buffer is thread-safe,
such as with a critical section.
> Seems to me like I want to send a message back to the thread
No, you should not do it that way, for 2 reasons:
1) you can't get the ThreadID of Indy's threads in Indy 10, nor should you.
The server's threading model is more complex then in Indy 9. Under advanced
scenerios, a socket can be managed by multiple threads, jumping from one
thread to another for different operations. That is why the Context class
exists in Indy 10 instead of providing direct access to the thread like Indy
9 did
2) sending a message to a thread requires a message queue, which would not
be as simple to implement in an Indy server because of the event handlers.
I support you could use the OnExecute event to call PeekMessage(), but you
definately should not use GetMessage() as that would block the thread.
Gambit
