Quote Originally Posted by Sam Hobbs
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 sure you read the full article?

2 paragraph's down from that that, he also states:

"However, there are ways you can add subclassing functionality to every process."

So subclassing a window in an external process is possible so long as the window procedure is mapped into its address space. This can be acheived by having your window procedure in a stanard DLL. See my post in the codebank.

General rule of thumb: You shouldn't always take Microsoft's words as engraved in stone.

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.
Granted, they are advanced functions, and you need to know what you're doing when working with them, but your argument of "just because they're debugging functions" really doesn't have any justification.

When suggesting for others solutions that require ReadProcessMemory and/or WriteProcessMemory, they should be told that the solution requires use of a debugging API.
The fact that they're listed under the debug API's in the platform SDK is irrelevent, and does not degrade their functionality; they're still part of the kernerl32 library.

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.
So by your logic, should I warn someone that they're using GDI API when I suggest BitBlt?

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.
I don't follow: How does the use of Read/WriteProcessMemory in my or your application allow a 3rd party hacker to take total control of the system?

(If he's that sophisticated, he can write his own application. No need to tamper with ours)

Yes, as far as I know, it does nothing we can't do ourselves
My point exactly. WM_COPYDATA is just like any other window message.

Note that I did not say that WM_COPYDATA is easier to process; you indicated that it is not easier.
Nor did I say it was more difficult. Window messages are window messages.

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.
I'm going to be repeating myself, but WM_USER is no "better" than WM_APP. Microsoft may use WM_USER for controls, and WM_APP for inter-application communication, but it's really a matter of preference.

Re-read my previous posts, as I would be repeating myself again.

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.
The system message table. When you call RegisterWindowMessage, a new value is added to this internal table (system-wide).

Most experienced software developers understand the value of flexible solutions such as RegisterWindowMessage.
Like I said, as long as you have control of both window procedures, it does not matter which method you use. Those "experienced software developers" can verify this.

We can keep going in circles here, but the underlying facts are:

1. WM_USER, WM_APP or RegisterWindowMessage are ways of creating a custom window message to communicate between applications.

2. To process these messages, you need direct access to the window procedure of the receiving window. In C, you already have access to it, whereas in VB you have to subclass. If it's an external process, you'll have to subclass in either case (using a DLL to map the procedure in the receiver's address space)

3. WM_COPYDATA is a generic message for sending data, and needs to be processed in the same way as any other message.

4. There are other means of transferring data, if you so desire, such as pipes, file mapping etc.