send info between apps

[yrwyddfa]

Yeah - they could've made it easier . . .
Most of the awkward looking API stuff here is for serialising/deserialising the message stream and putting it in and out of property bags.

[Wokawidget]

If you take a look at my VB6 multithreading example, it has code there which allows you to send VERY LARGE structured data between 2 apps, using the send, or post, message API functions.
The DLL that does this is called vbGatewayy.dll that I wrote.
Take a look.

Not sure if that's relevant

Woka

[Sam Hobbs]

Woka, I assume your sample is useful. For those applications that require something more complicated than what WM_COPYDATA is capable of, I assume it is worth evaluating. Note that the WM_COPYDATA message does automatically a lot of things that a program such as yours must do.

Since the WM_COPYDATA message is not as easy to process in VB as other messages are, and since VB makes COM objects so easy, it is probably practical to use a COM object. I am not sure of the terminology but I hope most people understand. Probably I mean an ActiveX component, but the term ActiveX is not clearly defined.

[moeur]

Summary

It's funny that the original poster has not posted anything here after the original post to clarify the problem. The ensuing discussion however was rather informative so I have compiled what I think is an accurate summary of the conversation. Please correct me if I erred.

As I see it there are two possible scenarios.
1. Both applications are "owned" by the poster (i.e. he has access to the source code of both.)
2. He does not have access to the source code of one of the applications.

Solution for case 1:
Subclass a window in each app to receive messages (yrwyddfa shows how to do that) and use WM_USER, WM_APP or WM_COPYDATA to pass messages back and forth (yrwyddfa again with an example).

Solution for case 2:
Subclass a window in your app to receive messages and hook the other app. The hook will have to point to a routine that resides in a WIN32 DLL which cannot be done with VB (I use VC++ for this). The "owned" app can then communicate with the DLL and hence the other app using the same technique as in case 1.

Notes:
1. Standard windows messages sent between processes, such as WM_SETTEXT and WM_COPYDATA, can contain pointers since the OS knows about these messages and handles the marshalling. If user defined messages such as WM_USER and WM_APP contain pointers, the pointers will only be valid in the address space from which they are sent. One way to handle pointers between processes in user defined messages is to use ReadProcessMemory to retrieve the data.

2. To make sure that your message is not being used by another application, you can register it with the OS with RegisterWindowMessage. It is probably safer to use the WM_APP range because some predefined window classes have already defined values in the WM_USER range.

3. WM_COPYDATA is great for sending text strings or data structures as long as the data structure does not have a pointer in it. If it does, you'll have to use ReadProcessMemory to get that data just like you would with WM_APP.

4. Take a look at Wokawidget's code if you want to see how complex it can get sending code between two applications. Warning: this code is not for beginners especially since it contains no comments. What’s up with that Woka?

[Wokawidget]

I think that sums it up

Comments...Hmmmm

I never use comments, they get in my way and annoy me. The 1st thingI do when I download someones code is I remove the comments.
This also means that you must manually figure out what code does. I have done this from the 1st day I started learning programming, 4.5 yrs ago. Personally I think the learning curve is steeper without comments.

I know others like them, and maybe some would be beneficial, but hey, no one is perfect

WM_COPYDATA cannot be used with PostMessage.

Woka

[headkaze]

This might help (my apologies if someone has already posted this, I couldn't be bothered reading the entire thread )http://www.thescarms.com/vbasic/PassString.asp

[Sam Hobbs]

Thank you, moeur. I know you are trying to help.

It's funny that the original poster has not posted anything here after the original post to clarify the problem.

It is more common than it should be. I usually avoid guessing and therefore just ask for clarification before proceeding further. For example, ice_531 asked

"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."

and Shaggy Hiker asked

"Also, do you have the ability to alter both programs."

I think the issue should have been left there, until clarification was provided.

My experience has been (in the CodeGuru forums) that when a vague question is asked and not clarified, it is common for it to explode into a lengthy discussion. That happens because there is not a topic specific enough to adequately limit discussion, and the vague nature of the subject likely results in differing understandings and points of views. For example Megatron posted comments with a couple or more mistakes.

One of the mistakes was "subclass the receiving app". Applications aren't subclassed; windows are. It was a simple mistake, and I realize that most people would understand what he meant. Note that I tried to be subtle and reasonable in my comment about it. However instead of clarifying what he said, he tried to defend it.

Megatron also said that it is possible to "pass the string in the lParam parameter" of a "WM_USER + X message", which is not possible. If Megatron meant that the string could be put into a lParam parameter, then it is possible to send only a few characters, not enough to be considered a string. If Megatron meant that the string could be sent by using memory outside the message and passing just a pointer in the lParam parameter, then it is necessary to also say that custom marshalling is required.

The ensuing discussion however was rather informative so I have compiled what I think is an accurate summary of the conversation. Please correct me if I erred.

What would help the most is to verify what we have said, before summarizing. Since you have created your summary using inaccurate information, it contributes to the problem, not the solution.

I do understand that you meant well, and I hope I have not discouraged you from helping in the future. The way you could help the most is, as I said, correct any mistakes that we have made. It does not need to be personal and should not be personal, but it is entirely possible to state facts without being personal. Just stating the facts I think is a mature solution.

Solution for case 1:
Subclass a window in each app to receive messages (yrwyddfa shows how to do that) and use WM_USER, WM_APP or WM_COPYDATA to pass messages back and forth (yrwyddfa again with an example).

No; the WM_COPYDATA does not need custom marshalling, but WM_USER and WM_APP messages do. Look at the documentation of the BroadcastSystemMessage, SendMessageTimeout, SendMessage, BroadcastSystemMessageEx, PostMessage, PostThreadMessage, SendNotifyMessage and SendMessageCallback message functions.

Solution for case 2:
Subclass a window in your app to receive messages and hook the other app. The hook will have to point to a routine that resides in a WIN32 DLL which cannot be done with VB (I use VC++ for this). The "owned" app can then communicate with the DLL and hence the other app using the same technique as in case 1.

Receiving messages in another application that cannot be by modified at the source code level is one thing, but how to process them in that other application is a more critical problem, and likely more difficult than simply receiving the messages. Therefore I think it is best to assume that this is not a requirement until it is stated explicitly that it is.

1. Standard windows messages sent between processes, such as WM_SETTEXT and WM_COPYDATA, can contain pointers since the OS knows about these messages and handles the marshalling. If user defined messages such as WM_USER and WM_APP contain pointers, the pointers will only be valid in the address space from which they are sent. One way to handle pointers between processes in user defined messages is to use ReadProcessMemory to retrieve the data.

As far as I know, what you are saying here is accurate, or at least close enough to being accurate. Except it should be stated that it is best to avoid use of ReadProcessMemory, at least in programs being developed for use by other people. I am working on getting some authoritative references on the subject.

2. To make sure that your message is not being used by another application, you can register it with the OS with RegisterWindowMessage. It is probably safer to use the WM_APP range because some predefined window classes have already defined values in the WM_USER range.

I think that what you meant is accurate, but not what you actually said. What you said seems to be saying that is probably safer to use the WM_APP range for message ids instead of message ids obtained using RegisterWindowMessage.

3. WM_COPYDATA is great for sending text strings or data structures as long as the data structure does not have a pointer in it. If it does, you'll have to use ReadProcessMemory to get that data just like you would with WM_APP.

No, use of ReadProcessMemory and WriteProcessMemory are not required. It might be possible to easily convert the data such that pointers are not used. If that is not possible and/or the data is large, then memory-mapped files are more efficient and safer than ReadProcessMemory and/or WriteProcessMemory.

[Wokawidget]

Memory mapped files?

Woka

[Sam Hobbs]

Memory mapped files?

Woka

I might be using incorrect terminology but it is correct to the extent that this is a common use of the term. I don't know how familiar you are with Memory mapped files, so I should try to define them assuming you know very little. If I don't do that well enough, then say so.

Memory mapped files is a common way for processes to share data; perhaps the most common. It does seem to be an indirect solution, and it probably is, at least somewhat. A Unix system, for example, has more direct functions for sharing memory; at least if my memory is accurate.

When a file is mapped to memory, a portion of memory in each process's address space is mapped to a common portion of virtual memory. The memory can be paged in and out, but that is not done unless physical memory is used to the extent that pages need to be swapped, whether they are part of a memory-mapped file or not. Data in a memory-mapped file can be accessed as efficiently as normal memory in an address space. In terms of efficiency, the memory is the same as the rest of memory for the process. ReadProcessMemory and/or WriteProcessMemory are very inefficient in comparison.

A memory-mapped file can be backed by the pagefile(s), for which the file becomes just a way to share memory. Believe me, that is a solution that is very, very common.