Seems subclassing can solve my problem. I'm a newbie on this. Could your guys send some sample code or some descriptions on how to do that?

Thanks a lot!

If you inject a DLL into another process, you can do it, as long as the DLL contains everything (the new WndProc). You can write a wrapper WndProc that communicates with the main app, but that will probably HORRIBLY degrade performance.

Steps for injecting:

- Get the proper security privlidges to mess with the target process
- VirtualAllocEx to allocate an area for a string
- WriteProcessMemory to copy a string from your process into that virtual memory
- CreateRemoteThread to start the "LoadLibrary" procedure and pass the string address as the parameter.
- BAM! Your DLL loads and does anything it wants within the target process.

Quote:Original post by Nypyren
If you inject a DLL into another process, you can do it, as long as the DLL contains everything (the new WndProc). You can write a wrapper WndProc that communicates with the main app, but that will probably HORRIBLY degrade performance.

Steps for injecting:
- blabla...

No, it has nothing to do with remote subclassing.

The problem I had with SetWindowsHookEx, was that it was only passed messages sent by SendMessage, which is not how the vast majority of WM_PAINT messages are sent to a message loop by Windows. To avoid flickering you need to inject a dll into the remote process using the method someone stated above, and capture messages by subclassing each window you want to draw on(or an entire class, typically by creating a hidden window and using SetSubClass, unfortunately this only affect subsequently created Windows). Performance dies quite bad with this solution, but I can't think of any better ones. When communicating with the main app, try to use PostMessage as appose to SendMessage wherever possible, as this will reduce some strain on the IPC.