This idea may be way off base but here goes. It's called going low tech...
Use files. the "client" writes a file to a designated folder with info it wants to send to the "server". The "server" checks this folder every half second or so to see if there is info to send to the comport. If there is do its thing and put the result in the same or another designated folder for the "client" to pick up again. IF there is an error the "server" will pop out a short error file. You can keep things synchronised by setting the filenames by date/time or sequence number so the client knows which file it is waiting for. Then delete (or move) the files after they have been read. The only problem you may have is if the server crashes or something - make a time out so if the client has sent something and hasn't got a result after 5 seconds then assume error and send again. Steve >>> "Jeremy Coulter" <[EMAIL PROTECTED]> 21/04/2004 8:34:48 a.m. >>> 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
