Mike


Another thought just wafted through my mind. If the amount of data isn't to large or complex what about using a memory mapped file, not a table.

I can't help you but the codegear newsgroups should have some stuff.

Roy Lambert

In general it does not matter what was used to write the app to communicate
with any other application (delphi or non-delphi). Generic term is IPC
(Inter-process communication) and you can use things like sockets, named
pipes, shared memory, memory mapped files, activex(com), windows messages,
etc.

Depending on what you need it might be easiest to use some of the simpler
methods : ActiveX/COM works well but might be bit of a pain to implement.
Windows DDE might be useable for you - again depends on what you need.

Using windows messages and WM_COPYDATA for example is also pretty
straightforward: and you just need to find the windows handle and send
message to it
(http://msdn.microsoft.com/en-us/library/ms649011%28VS.85%29.aspx).  Not
sure how good it is but google serach showed number of links including this
which seems to explain it a bit :
http://delphi.about.com/od/windowsshellapi/a/wm_copydata.htm

The other application does need to be running (and accepting data whatever
method you use to send it).

DLL is just a library of functions and itself does nothing for
communciation - in your case you are taking advantage of the ability to
compile a DLL in Delphi and then use it in C/C++/.Net/etc  languages by just
importing functions.

Raul



> Could you please explain how a non Delphi app can be instructed to
> perform an action by an App written in Delphi.  At present my non
> delphi app simply calls the DLL when needed (or could be at fixed time
> intervals) and passes some data across  ie its the non delphi app that
> initiates the action needed   Wouldnt the DLL need to be always running
> (like an .exe) so that it could receive messages  I have assumed that
> my present DLL could not receive messages when not being accessed from
> my non Delphi App

Mike Saunders wrote:
> Norman Rorke wrote:
>
>> Can I suggest you look at this
>> http://www.eldos.com/msgconnect/desc.php
>>
>> It is a cross-platform inter-application communication utility we
>> have been using for years. Works across the network and has a tiny
>> footprint. We also use it to communicate with a COM dll that is being
>> accessed by non-Delphi apps.
>>
>> Norman Rorke
>> Desktop Financials Ltd.
>
>
> Thanks that is a useful link to have
>
> I still am a little confused though
>
> Could you please explain how a non Delphi app can be instructed to
> perform an action by an App written in Delphi.  At present my non
> delphi app simply calls the DLL when needed (or could be at fixed time
> intervals) and passes some data across  ie its the non delphi app that
> initiates the action needed   Wouldnt the DLL need to be always running
> (like an .exe) so that it could receive messages  I have assumed that
> my present DLL could not receive messages when not being accessed from
> my non Delphi App
>
> Thanks
>
> Mike
>
>


Mike

In this case you would use an asynchronous protocol whereby the Delphi
dll will post a message (initiated by the non-Delpi app) to the Delphi
application. The message will trigger a listener event in the main app
that will interrogate and respond to the incoming message. The response
from the Delphi app will similarly trigger an event in the dll that is
able to process the response and feed something back to the host (non
Delphi app).

It is also possible for the delphi app to initiate communication, with
the anticipation that the dll may not be currently running, and hence
not respond. I use this for example to check whether there are any
non-Delphi apps accessing the database before initiating a major data
related process. In this case the message is addressed to all listeners
and would be picked up by all running dll sessions on the network. If I
do not receive any responses I can assume its safe to go ahead.

What is also nice about this utility is that you can make up your own
message structures that only the dll and Delphi app understand.

I hope this makes sense.

Norman

Thanks guys

I guess we have just about covered all the angles now and plenty to
think about

Mike