send info between apps

[quaso]

How can I send data (strings) between 2 standalone apps?

[ice_531]

Need to elaborate a bit on your problem. You want to send text to another application from your app? Or send text/data using a connection such as winsock to a server side app.

[Shaggy Hiker]

Also, do you have the ability to alter both programs. If so, you would probably get quicker answers in a different forum, since the solution would probably be winsock rather than API.

[Megatron]

If they're on the same machine, send a WM_USER + X message. You can pass the string in the lParam parameter.

Then subclass the receiving app, and check for the WM_USER + X message.

[packetVB]

Look at CreateFileMapping API. Passing it a null for the name of a file will let windows know you want share memory. You give the shared mem a name when creating and another app can open using that name.


packetvb

[duniaseng]

Hi Megatron,

I am facing a similar issue. i appreciate that u can elaborate on WM_USER + X message. even better if u have sample code.

Thank you very much

[Calibra]

Named pipe's and Mailslots are capable of communicating between apps

[Sam Hobbs]

Megatron, I am not sure what you mean by "subclass the receiving app", but I doubt that it is easy.

A WM_USER message would work only for very short strings. The first suggestion should be the WM_COPYDATA message, which can be used for much larger strings. The WM_COPYDATA message will do a CreateFileMapping for you. There is very little to be concerned about when using the WM_COPYDATA message except the receiving application must copy the string (and/or other data) when the message is processed; that is, before the message processing function returns.

The WM_COPYDATA message can be very useful and very easy to use. If the requirement is more complex than what can be done using the WM_COPYDATA message, then there are other possibilities. Look at "Interprocess Communication" (IPC) in the Platform SDK. An ActiveX Component is relatively easy for VB programmers and can be a very useful solution that many people might not think about.

[Megatron]

Megatron, I am not sure what you mean by "subclass the receiving app", but I doubt that it is easy.

Subclassing is a means of accessing the window procedure from VB. Generically speaking it replaces the default window procedure with a custom one. It's definetly not a difficult task, as window procedures are essential for programming in Windows.

A WM_USER message would work only for very short strings

Well, sure, if you're passing a mystery novel through a window message, then yes; you're going to run into problems. Maybe quaso can fill us in on the length of strings he wants to pass.

The WM_COPYDATA message can be very useful and very easy to use

As opposed to what? WM_USER?

They're both window messages, and are subject to the same constraints. Anything that can be done with WM_COPYDATA can also be done with WM_USER.

More over, WM_COPYDATA is a custom message. This means that there is no default action for it, and it's up to the user to process this message (if at all). And how do we do it? You guessed it: Subclassing.

[Sam Hobbs]

Subclassing is a means of accessing the window procedure from VB.

Yes, I am familiar with subclassing windows. However you said "subclass the receiving app", and that is what I am not sure of. If you meant "subclass the receiving application's window" or something such as that, then that I understand.

Generically speaking it replaces the default window procedure with a custom one. It's definetly not a difficult task, as window procedures are essential for programming in Windows.

Subclassing a window for an application that is within the same address space is relatively easy, at least for C and C++ programs. I assume there are enough existing samples of doing that in VB too. However when using VB some messages will be more difficult than others to process.

In this context, the requirement is to subclass a window in another address space, which is much more complex. I assure you it is not easy for a beginner to write all the code themselves to do that, and it should not be easy for a beginner to simply copy a sample if the beginner needs to modify the code. When crossing address spaces, there are too many things that a person could make a small mistake with and mess up the system.

Well, sure, if you're passing a mystery novel through a window message, then yes; you're going to run into problems. Maybe quaso can fill us in on the length of strings he wants to pass.

It is not possible to put a pointer in most Windows messages, including none of the WM_USER messages, and then send the message accross address spaces. The pointer would be totally meaningless in another address space. Therefore, without pointers, it is possible to send a maximum of four (16-bit) Unicode characters or a maximum of eight ASCII (8-bit) characters.

As opposed to what? WM_USER?

They're both window messages, and are subject to the same constraints. Anything that can be done with WM_COPYDATA can also be done with WM_USER.

There is definitely a difference. The WM_COPYDATA message is provided to overcome the limitations of the other messages. Just search the MSDN for what it says about the WM_COPYDATA message.

More over, WM_COPYDATA is a custom message. This means that there is no default action for it, and it's up to the user to process this message (if at all). And how do we do it? You guessed it: Subclassing.

If the WM_COPYDATA message is more difficult to process than WM_USER messages, then that is unfortunate, since the WM_COPYDATA message is so useful and eliminates most or all of the technicalities that might be a hassle for VB. However I really doubt that there are not any samples of processing the WM_COPYDATA message using VB.

As I indicated, subclassing within an address space is easier than across address spaces, so if the WM_COPYDATA message must be processed by subclassing a window, then that I assume is easy, since Microsoft tries to make things as easy as possible for VB programmers.

Note that the Platform SDK warns against using messages with message ids in the WM_USER range; it is better to use the range WM_APP through 0xBFFF. The WM_USER range is usually safe but it is just as easy to use WM_APP instead of WM_USER. Even better than WM_APP is to use the RegisterWindowMessage function to retrieve a message id. However none of those will allow you to send a pointer in the message that is valid in another address space.