Fw: [DUG] Possible solutions

[Phil Middlemiss]

Title: Message

Posted privately to Jeremy by mistake,   The Indy threads shouldn't be an issue. eg, the Server receives data from the client, sends something out of the comport and sits there doing Application.ProcessMessages until it is ready to send data back (presumably that it has received from the com port) - all in the same routine. Even though the routine may be entered more than once before the first entry exits, as long as you are careful about managing global data, you should be fine.   I did something a little bit similar to this a while ago - I had a separate Manager class that held onto the "transactions" until they had been processed and a return value obtained. The routine that received the Indy thread basically passed the data to a "slot" in the Manager class and waited until the Manager class showed that that slot had been processed and then grabed the result and sent it back to the calling thread. The Manager class was using a timer to continuously check it's slots and do any work that it had to.   May be too much work - depends on how much you want to change your server program.   Cheers, Phil. ----- Original Message ----- From: Jeremy Coulter To: [EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 8:34 AM Subject: [DUG] Possible solutions Hi all. I think I have worked myself into a corner and I am missing an obvious answer here that I cant see because I am thinking about it too much...if you know what I mean. Heres the senario :-   I have an application that is connected to a comport. (the server) I then have another application that needs to output the data to a comport...the same comport (the client).   This situation has come about after the intial design of the "server" app....its not really a server but the analogy fits. The "client" needs to pass some info to the "server" because its connected to the comport, and 2 apps. cant share the same comport.   So, I have tired using TCP/IP with INDY controls to pass data to the "server", and that works fine, BUT then the server needs to pass back data to the client, i.e. the data back form the comport is parsed and a result generated, which is then passed back to the client. The problem here is, this might take a few seconds, and in that time, maybe another request has been sent to the server to do something else, and because INDY uses threads you loose the reference to the first thread that data was received on, so you cant pass data back on that thread...etc.   So, I used MailSlots, and I did have to deal with a message being sent to every installed network protocal, but thats ok, it sometimes was a wee bit unreliable, or would hand the server app. when it tried to close....for what ever reason.   This app. would be installed on win98 machines and up, and both client and server are on the same machine.   So, why not make teh client and server ONE app? because the server is pretty much only got a very simple interface and is really only designed for logging some data, and I was trying to keep the 2 apps. seperate.   So, I hope this is enough info for someone to either say...hey persist with "this" line of development, or hey, try "this" line of development.   Like I say, I think I have got to that point where i cant think about it clearly anymore because I am getting a bit too anxious about it.   Any help appreciated.   Cheers,   Jeremy Coulter     ------------------------------------------------------------------------ All email scanned with Nortons Antivirus 2003 ------------------------------------------------------------------------   _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi