send info between apps

[Sam Hobbs]

You're confusing "subclassing" with direct access to a window procedure.

No. I know what window subclassing is. See the second paragraph of Safe Subclassing in Win32 in which it says:

an application cannot subclass a window or class that belongs to another process

You probably think that is not accurate, eventhough it is in the MSDN Technical Article on the subject. So I won't try to convince you otherwise, but I hope I am saving other people's time.

If, on the other hand, you simply need to send data to a specific address location in this external process (one-way communication) then WriteProcessMemory will do the trick.

ReadProcessMemory and WriteProcessMemory are debugging functions. They are not listed in the IPC APIs. I certainly recommend not to use functions such as them in production applications, but you can if you want to. When suggesting for others solutions that require ReadProcessMemory and/or WriteProcessMemory, they should be told that the solution requires use of a debugging API. People should not allow application software to use debugging APIs for any other purpose than debugging, since hackers and viruses and worms could use them to get total control of our systems. People should be warned about use of ReadProcessMemory and WriteProcessMemory. You can use them in your software but when advising others you really need to warn them.

WM_COPYDATA is a window message. It's no more special than WM_LBUTTONDOWN, or WM_CLOSE or any other message. What you're probably referring to as "special" is it takes care of copying the data into the receiving process's address space, though there's really no magic to it.

I did not say it is magical. Yes, as far as I know, it does nothing we can't do ourselves. However it does do a lot. It does not use ReadProcessMemory and/or WriteProcessMemory or anything like that. It does do the same things that we would normally transfer data across address spaces. The fact that it does that makes it special, since it is different from the other messages.

Whether WM_COPYDATA is easier to process than a customized WM_USER message is a subjective question.

No easier or harder than any other window message.

Note that I did not say that WM_COPYDATA is easier to process; you indicated that it is not easier.

WM_APP isn't "better" than WM_USER, nor is it the other way around. Granted, Microsoft generally uses WM_USER in controls, rather than main appliation windows, but so long as you have control of both window procedures, it really doesn't matter what range of values you use (either WM_USER or WM_APP).

It is just as easy to suggest use of WM_APP as it is to suggest use of WM_USER, so it is better to suggest to others that they use WM_APP. There is no reason not to suggest to others that they use WM_APP instead of suggesting use of WM_USER.

RegisterWindowMessage creates a new message identifier in the message table, and it stays there for the duration of your windows session. There's nothing wrong with using this, though it offers no significant advantage over WM_USER if you are writing both applications and are in charge of handling the message. It does come in handy when you need to send to HWND_BROADCAST for example (but that's not the issue here).

Message table? What message table? Does VB have a message table? If VB has a message table, then RegisterWindowMessage could not update it, since RegisterWindowMessage is a SDK function that knows nothing about VB.

Most experienced software developers understand the value of flexible solutions such as RegisterWindowMessage. I understand that you don't see the value, but many others do. My guess is that most developers of commercial software require use of RegisterWindowMessage when messages are sent across applications.