I got the Plan B working (SetTimer+GetMessage) for SimpleIPC.
However, it is not possible at all to get TSimpleIPCServer.PeekMessage to NOT read the message, i.e. to respect DoReadMessage=False parameter.
Every message queue accessing function in Windows (e.g. PeekMessage, GetMessage) automatically dispatches all incoming *sent* messages by directly calling the associated WindowProc method. So it's not possible to check if there are incoming *sent* messages in the queue without delivering all of them at once.
The only way to make TSimpleIPCServer.PeekMessage respect DoReadMessage=False parameter is to store locally all sent data streams and then feed them to user on ReadMessage call. Meanwhile, TSimpleIPCServer.PeekMessage with DoReadMessage=True can loop trough ReadMessage call until there are no more buffered messages left.
There is a concern that locally buffered data streams will keep growing if server stops processing them while clients keep sending them. We can either (A) delegate this concern to the user of the IPC server, or (B) hard code some limit on the maximum number of buffered data streams. Any recommendations?
There are alternative IPC mechanisms available in Windows (Pipes, Sockets, DDE, etc), but that might be like opening another can of worms. I'm still confident that we can get a fully functioning IPC going using WM_COPYDATA, it just might get a bit more complicated.
Denis _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
