Communicating between two programs??

[Doug Deming]

I need to write a program which acts as a brige between two
Windows applications (call them A & B) allowing “A” to
send msgs to “B” and vice versa. For example, "A" might send
a request for data from "B". "B" needs to respond to "A"
with the requested data immediately. I do not want to use a
polling method to check for incomming messages, rather, I
want any incomming msg to trigger some event so the
receiving app will reply quickly.

I was thinking about a 32bit DLL using the "CALL DWORD"
command. First "A" and "B" would register their receiving
function with the DLL. Then when the "A" sends a msg to "B"
it does it by the "CALL DWORD" which would send the msg
directly to "B's" receiving function and vice versa.

Is this the best method or what do you recommend?

Thank you!


------------------

[Edwin Knoppert]

I belief that a exported function in the exe's would do.
But i'm not sure.

I read (and used) that WM_SETTEXT between processes is using filemapping internally.

WM_SETTEXT is really easy and even possible between a 16bit and 32bit app.

Sharing data should be done using filemapping.
Notifications.., i'm not sure however, you can link processes.
If you do that i guess you can do anything.

On the internet is a sample for VB ForceForegroundwindow.
This shows 'linking' processes.


------------------
[email protected]

[Eric Pearson]

Doug --

If I understand what you are saying about using CALL DWORD, it simply won't work. You see, as the two EXE programs link to the DLL, each will be operating in its own "process" and they will be invisible to each other. Each EXE will have its own complete set of GLOBAL variables in the DLL. They cannot "share data" in this way. Even if you call an exported function that is located in a different EXE (like two EXEs calling each other's functions) the GLOBAL data will definitely not be shared.

The general topic that you are describing is called InterProcess Communication, or IPC. Windows makes several different IPC functions available, each with their own advantages and disadvantages. Common techniques include Mailslots, Named Pipes, Anonymous Pipes, and Memory Mapped Files, and there are several others. Search MSDN for "IPC" and you will find lots of information.

If you can be more specific about a few things I can give you some pointers. For example, will the two programs always be running on the same PC, or might they have to communicate across a network? Will the programs always run on Windows NT or 2000, or might they run on 9x or ME systems? Is one program the "child" of the other, i.e. does one program launch the other, or are they 100% separate programs? How large are the messages that must be passed back and forth? Is the communication "message" oriented, or is it more like a stream of data with no specific "block" or "segment" structure?

Depending on your answers, it will become clear which is the best IPC method to use...

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Scott Turchin]

There is a package getting ready to be, or already released to do this for you, pretty simple too....

I'll email Jim and see how it's coming along, what I've seen of it looks right nice...


Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Steve Hutchesson]

Doug,

There are a couple of ways to perform inter-process communication that
are both reasonably straight forward.

Registering a private windows message as follows is clean simple and tidy.

WM_SENDMSG = RegisterWindowMessage("Inter_Process_Message_A")
WM_RECEIVE = RegisterWindowMessage("Inter_Process_Message_B")

You then use,

SendMessage %HWND_BROADCAST,WM_SENDMSG,0,0

and at the other program,

Case WM_RECEIVE

You can register any unique name that suits your requirement and if the
string is identical in both apps, they can communicate this way.

To pass data,

GLOBAL cds as COPYDATASTRUCT

--------

a$ = "This is a test !!!!"

cds.dwData = 0
cds.cbData = len(a$)
cds.lpData = StrPtr(a$)
SendMessage lParam,%WM_COPYDATA,hWin,ByVal VarPtr(cds.dwData)

and at the other app, process the message,

Case %WM_COPYDATA

With more work you can use memory mapped files if you need this type of
capacity.

Regards,

[email protected]

------------------

[Doug Deming]

Thank you everyone! I will study your recommendations.

------------------

[Herman Kieskamp]

Doug, is it a threaded app or not?
If it is not a threaded application, you could consider a controlling
exe, which calls the seperate programs as dll's one by one, while
passing the info through.

Herman..


------------------