What is the best way to do application data exchange in Delphi without sockets?

Question

I need a few of my related applications to communicate to each other (exchange data and initiate actions). Requirements are without packages and no sockets. So I guess that leaves named pipes, WM_CopyData (like Skype does it) and command parameters. What are your best practices?

Answer 1

You probably have a couple of options.

Beyond what you already have:
DDE
Memory Mapped Files (MMF)
MailSlots

I would probably go with either the Pipes or the MMF.

There are a couple of free MMF components that you can download, Deborah Pate has a set of freeware classes you can use. MapFiles.zip

Check for MailSlots on Torry's site.

The final solution might be dependent on the amount, size and frequency of the data transfers that decide which option you choose.

Answer 2

I would advise to use COM in this situation. (Attention: not COM+, not ActiveX, not OLE; COM, just COM.)

Since Delphi 7 (or an earlier version, I'm not sure), this is easily done by adding a Type Library to the project, and an Automation object.

Advantages are it's pretty widely supported, both within Delphi (the Type Library Editor has everything you need and updates your code, and COM internals and registering are catered for from the ComServ unit), and outside of Delphi (I use it in a number of project to interact with all sorts of applications: C++ projects, Word and Excel documents using VBA, oldskool ASP...).

An only disadvantage I encountered may be threading issues, in normal applications, a plain CoInitialize(nil); at application startup will do, in more complex applications, you need to think about 'threading apartments' or use free threading and do your own locking. (Which in some cases you've been doing already.)

Answer 3

Do not use COM, too much overhead (variants) and you must register you .dll or .exe (and it gives a lot of weird installation + update problems).

I should go for MMF, I use this for communication with Windows Services. I use the following TGpMessageQueueReader and writer for this: http://17slon.com/gp/gp/gpsync.htm

Answer 4

Another alternative which is dirt simple to implement is to use the database to pass information.

Not overly elegant, and it does use a lot of overhead, but if your application is already data-aware (ie has a database as part of it), then using a table or two to pass information is pretty easy.

Answer 5

You could use simple files: One side writes to it, the other reads. If you need two way communication, just use two files, one for each direction.

Of course this is not really high performance.

Answer 6

Is'nt this the sort of this that RemObjects is good at? Bri

Answer 7

Another vote from me for named pipes, for the data exchange. I like them slightly more than mmap files, since the win32 pipe APIs give you some nice choices out of the box: sync/async, byte stream vs message packets, simple ReadFile/WriteFile calls. All of which you could do yourself with mmaps... but pipes are already there...

And you can control access with security attributes -- which isn't an option with WM_CopyData. This might not be an issue immediately... but can be handy to have the option, even if you don't care who sends your app messages. For me, this was helpful when Vista came along, and suddenly user apps ran in a separate session to my service. Was good that tweaking the security attributes was the only thing needed to get things working again.

For "initiating actions", you might be able to get away with something as easy as some named Events, and not worry about sending messages at all? The interested parties simply wait for it to be signalled.

Personally, I'd avoid COM unless you have to specifically support COM-based clients.

Answer 8

If you want to pass data, call functions etc then use COM, however if there are lots of calls be aware that COM is slow. Also you might have to register the application with "xxx.exe /Regserver", before it will work.