send info between apps

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

[Wokawidget]

Any exmaples of code?

Woka

[Sam Hobbs]

Any exmaples of code?

Woka

How did you search? Whatever you are using to search is no good, since there should be many to be found. As soon as I get through doing things such as checking ther weather, I will look for samples using VB, and hopefully we can help you in knowing how to search.

[Wokawidget]

Hahaha. You sarcastic sod Hahaha.

OK. I will search. I was just wondering if you had any small samples to hand. Not actively looking for this code as I have no need.

Woof

[Sam Hobbs]

I did not know of any samples, expecially not VB samples. There are many more samples that use the C/C++ languages but the following are two that use VB:

Visual Basic Samples by Karl E. Peterson (MapFile.zip)
Binaryworld - Sharing Data Between Processes Using Memory-Mapped Files ... [ VB -> Memory ]

Also, the MSDN previously contained an online copy of Hardcore Visual Basic, in which there is an article called "Shared Memory Through Memory-Mapped Files".