Readers Respond: Real World Examples Needed: Why/What do you Send Between Delphi Applications?

Responses: 16

What's your practice? Have you ever needed for two of your Delphi applications to communicate? Why? How do you send information between your Delphi applications? What do you send? Let us learn something new from your experience - give us some real world examples. Why do you Communicate?

Programming

Data from cash registers to Delphi Applications; from other Applications like Tensai2000 communication program of uniwel cash registers.

—Guest Isidro M. Lahora

I Use Asta/Sockets

Built an entire advertisement platform for cybercafes using Asta/Sockets. I send huge amounts of compressed ads(images) and other info from ad servers to clients machines in a asynchronous way. Works very well

—Guest Gath

HTTP / WebService

Indy components make easy to handle HTTP server embbeded in application ; so wee use that. Write and read from/to Sockets sucks, and are too low level work ! The use of WebService allows us to exchange real objects (OOP) between two applications so that you don't have to serialize objets !

—Guest FreeBen

windows messages and midas

Our application has a core component and multiple application components that all communicate with the core. We use windows messaging (user-defined) to send announcements / commands between the core and the applications. We use Midas, with a tDCommConnection in each application for more complex data transfers and remote calls. We also use the tClientDataSet to access file-based local data that is periodically synchronized to data in the remote data base

—jfitzhugh

File (!?)

I am old fashioned (and I think the only one). I use a lot of file communication where the data can be inside the file and/or on its name.

—Aryldo

Sockets & Windows Messages

We have used both. Sockets mainly for intermachine communications and Windows messages when only simple (and local machine)communications are needed.

—Guest ct

Sockets

Sockets with Indy Components, sometimes xmlrpc. Its always best to keep it abstract so that one day when you have to switch to something not-Delphi its not a PITA. I always run away (as fast as possible) from memory mapped files/pipes/windows messages.

—Guest crazy

Memory Map files

I prefer to use Memory Map Files. Using this is a bit odd but still usable with a some of work.

—Guest Yogi Yang

depends

Memory-mapped files, pipes, sockets. For simple sending of command line parameters, I found JclAppInst unit from the JCL (http://jcl.delphi-jedi.org/) useful. When you need to execute code in another process, a quite nice way (IMHO) is to use DataSnap. Local (same process), Socket and HTTP transports are already provided. I've written a memory-mapped file transport and now I can switch between these at runtime as needed, to use memory-mapped files across processes for the local computer, sockets or HTTP for remote computers (these require a socket server and a web server, respectively, to be running on the target computer). The client (calling) code remains the same. Because of the type library generated Pascal code, it's type-safe (checked by the compiler). An example of why you would need to split your executables into two separate processes is if they need to run under different user accounts, I've blogged about it here: http://tondrej.blogspot.com/2007/06/datasnap-to-rescue.htm

—Guest tondrej

Windows messages

We have little communication, but the few cases, are covered by windows messages (PostMessage). In case we need more info, the sender write info ona shared buffer (generally registry) that the receiver read. There's another case, where we are using RemObjects; among the channels it have, there is a WindowsMessage one.

—Guest Guillermo

Pipes, Sockets mailslots

I have a large (60k lines of code) project which has a GUI maintained in D5 (i nightmare these days) and a engine written in d2007 now. I use a pipe and a socket to allow communication between the two either locally or over a network. I basically use the GUI to create a setup which a DOS based program can process either locally on a server. I use a pipe or a socket to pass the output back to the GUI for the user.

—caniremember

Named Pipes or Mailslots

When getting one program to update the diaply of another across a network, I use Mailslots. Although their delivery is not guaranteed, and so cannot be used for critical messages, they do work across an entire domain, even with the possibility of sending the mailslot to every machine on the network. This is how Microsoft's early IM, WinPopop, used to work. Now I use Named Pipes more. Guaranteed delivery and even used as a mechanism for communicating with SQL Server. Can communicate across a network but only to one PC at a time, not a global broadcast if this is needed. If the applications are guaranteed to reside on the same PC then Windows messages are still useful. But not in Services any more from Windows Vista - you have to use Named Pipes to communicate with a Service.

—Guest J

Sockets

With sockets your program can communicate on a same machine or throught the internet. Best for me.

—Guest yome

Communication for application automation

I usually needs one application to drive another one. For example I made a specialised text processor so the main app would instruct the WP to create a new document using a specific template (amongst 140 templates) then later when certain conditions where met, the WP would turn the document into a pdf without direct user intervention. I send messages with parameters between apps and it works fine.

—Guest Didiergm

I use pipes or sockets.

Hi, good point. I prefer to split my Systems into several single exe-files and let them communicate through pipes or sockets. But I think, such things would be perfect to integrate into Delphi 20xx inside TApplication. I am also missing TApplication.UniqueInstance property and have you ever wondered why TApplication is not the Root-Node in Delphi's "Structure" window ?

—Guest sam

commands

I send text commands between two (actually a master and several clients) programs telling each other what to do and what has been done. In addintion, the clients regularly send the filename of a picture of what they currently "see". Each of the programs can run on the same computer or on any other computer on the network. No, it is not spyware but an application for automatically gathering data on road conditions running on sevaral vehicles in our fleet.

—Guest dummzeuch