Overriding another process' WndProc

[chep]

Digging into the "Drawing Desktop" thread idea and Phil's "Melt", I was wondering if there was a simple way to install a new WndProc for the adequate desktop window (SHELLDLL_DefView).

Ideally this would allow to override the WM_PAINT message and a few others with custom handlers, and let all other messages go through the original WndProc.

The problem I am now facing is that SetWindowLongPtr(GWLP_WNDPROC) won't let me subclass a window from another process. And SetWindowsHookEx doesn't seem to be able to prevent a message from being processed by the original WndProc (or did I misunderstood the docs?), and AFAIK it doesn't permit to hook a single window.

Even the evil "dll injection" method doesn't seem to fit this task, as this would require to retrieve the Explorer.exe instance actually owning the desktop, which may not be an easy task if multiple instances are running (unless there is a simple way to retrieve a process instance from a given window handle? I'm not aware of that...).


For now I have no idea about how to properly implement message *trapping* (not hooking) in this context.
Anyone got a clue? ::)

[donkey]

unless there is a simple way to retrieve a process instance from a given window handle

PID dd ?

invoke GetWindowThreadProcessId, [hWnd], OFFSET PID
invoke OpenProcess, PROCESS_ALL_ACCESS, 0, [PID]
mov [hProcess], eax

[chep]

Thanks Donkey!

At least I could easily inject a dll if there is no cleaner solution.
:U

[MichaelW]

Could you use a WH_GETMESSAGE hook?

[hutch--]

There is another approach, don't use the window at all, start another window of the same size over it, capture the image then do what you like with that image. You can easily enough make the new window a child of the parent as getting the desktop handle is easy so without having to try and hook another process at all, you should be able to visually change the appearance this way.

[chep]

Michael,

Right! I just reviewed the docs and saw that a WH_GETMESSAGE hook allows me to modify the message, so setting it to WM_NULL after custom processing should trap it as expected. I missed that the first time...


Hutch,

Indeed that should be far easier to implement as I wouldn't need to mess with Explorer's behaviour.
All I should have to do is put the new window at the correct z-order (just below the listview) so that the desktop remains functional. I'm gonna test this immediately!


Thanks for the suggestions guys! :thumbu

[chep]

Well,

I have tried both methods and technically they both work.

But no luck, I didn't manage to do what I wanted...
It appears that the desktop's Listview control is responsible for drawing not only the icons but also the background color/wallpaper. Whenever an icon is redrawn the area under and around the icon is also redrawn, using the background color or wallpaper.

So I'm giving up (at least for now). I really can't figure how to properly replace the desktop's background drawing routine while keeping the Listview control fully functional.

:(

[zooba]

One of the Winamp visualisations can do exactly what you're after. That might be a direction to look it. It's the Advanced Visualisation Studio that comes with Winamp.  :thumbu

[chep]

Thanks for the info zooba. :U I'll look into it ASAP.