Actually this DID go thru my mind at one point. There is the Windows event that gets fired when a dir changes, and there are some comps. out there to encapsulate it. hmm....sounding good....I will put that on my list.
Jeremy -----Original Message----- From: "Steve Aish" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Wed, 21 Apr 2004 09:03:56 +1200 Subject: Re: [DUG] Possible solutions > 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 _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
