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

Question

I need some of my related applications to communicate with each other (exchange data and initiate actions). Requirements have no packages and no sockets. Thus, I assume that leaves named pipes, WM_CopyData (e.g. Skype) and command options. What are your best practices?

Answer 1

You probably have several options.

In addition to what you already have:
DDE
Memory Mapped Files (MMF)
Mail Slots

I would probably go with either Pipes or MMF.

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

Check out MailSlots on the Torry website .

The final decision may depend on the amount, size and frequency of data transfer, which determine which option you choose.

Answer 2

I would advise using COM in this situation. (Note: not COM +, not ActiveX, not OLE; COM, just COM.)

Since Delphi 7 (or an earlier version, I'm not sure), this is easy to do by adding a type library to the project and the Automation object.

The advantages are pretty widely supported as in Delphi (the type library editor has everything you need and updates your code, and internal COM modules and registration are served from the ComServ module) and outside Delphi (I use it in a number of projects to interact with all kinds of applications: C ++ projects, Word and Excel documents using VBA, oldskool ASP ...).

The only drawback that I encountered may be problems with threads, in ordinary applications simple CoInitialize(nil); when you start the application will work in more complex applications, you need to think about "stream apartments" or use a free thread and make your own lock. (Which in some cases you already did.)

Answer 3

Another alternative that is easy to use is the use of a database to transmit information.

Not too elegant, and it uses a lot of overhead, but if your application is already aware of the data (i.e. has a database as part of it), then using a table or two to convey information is pretty simple.

Answer 4

You can 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 a very high performance.

Answer 5

Another vote from me for named pipes, for data exchange. I like them a bit more than mmap files, as the win32 APIs provide you with some good options: sync / async, a stream of bytes and message packets, simple ReadFile / WriteFile calls. All you could do with mmaps ... but there are already pipes ...

And you can control access with security attributes - this is not an option with WM_CopyData. It may not be a problem right away ... but it may be convenient to have this option, even if you don't care who sends your application messages. This was useful to me when Vista appeared, and suddenly user applications started a separate session of my service. It was good that setting security attributes was the only thing necessary for everything to work again.

For “triggering actions”, can you get away with something as simple as some of the above events, and not worry about sending messages at all? Stakeholders are just waiting for this to be communicated.

Personally, I would avoid COM unless you specifically need to support COM clients.

Answer 6

Do not use COM, too many service (options), and you have to register you .dll or .exe (and this gives a lot of strange problems with installation + updates).

I need to switch to MMF, I use this to communicate with Windows Services. For this, I use the following TGpMessageQueueReader and writer: http://17slon.com/gp/gp/gpsync.htm

Answer 7

Doesn't it look like RemObjects is good? Bree

Answer 8

If you want to transfer data, call functions, etc. then use COM, however, if there are many calls, keep in mind that COM is slow. You may also need to register the application with "xxx.exe / Regserver" before it will work.