使用链式 WndProcs 时正确清理

Question

When building a chain of WndProcs using SetWindowLongPtr , we store the parent WndProc (the one that has less importance in the chain), so we are able to restore it and call it, like so:

LONG_PTR oldProc = SetWindowLongPtr(hWnd, GWL_WNDPROC, &myWndProc);

WndProc myWndProc(HANDLE hWnd, ...) {
  return CallWndProc(oldProc);
}

This is just a rough pseudocode from the top of my head, so please don't focus on that.

The problem with this, however, is, that when trying to remove myWndProc from the chain, like so:

SetWindowLongPtr(hWnd, GWL_WNDPROC, oldProc);

We effectively set the proc, that was in place when first hooking, as the topmost WndProc. This means, that all WndProcs, that have been added after myWndProc (eg all kinds of Overlays), suddenly won't be called anymore. Furthermore all hooks that are added afterwards point to invalid memory with their oldProc .

This means, hooks done that way can't be properly unloaded without messing something up. While this would be fixable if all WndProcs belong to the same (our) codebase, this is not fixable with external code.

I haven't found a WM that would be called when a new WndProc is set, so it's also not possible to keep track of which WndProcs have been registered after the current handler, so one could re-build the chain. That would still not solve the issue with invalid oldProc s.

Is there something else where the WinAPI can help fixing this problem? Afaict using SetWindowLongPtr in that way does something like creating a child window(?) that way one could maybe query something?

Or is the bottom line just, that a WndProc cannot safely be unloaded anymore?

Answer 1

Is there something else where the WinAPI can help fixing this problem?

Yes, actually. This is exactly the kind of situation that SetWindowSubclass() was introduced to address. Let it handle the chaining and unchaining for you. Don't use SetWindowLongPtr(GWLP_WNDPROC) at all anymore.

SeeSafer subclassing and Subclassing Controls Using ComCtl32.dll version 6 for more information.

That being said, depending on why you are subclassing, SetWindowsHookEx() or SetWinEventHook() may provide an alternative hook you can use for your intended purposes.

Answer 2

We effectively set the proc, that was in place when first hooking, as the topmost WndProc. This means, that all WndProcs, that have been added after myWndProc (eg all kinds of Overlays), suddenly won't be called anymore. Furthermore all hooks that are added afterwards point to invalid memory with their oldProc.

This means, hooks done that way can't be properly unloaded without messing something up. While this would be fixable if all WndProcs belong to the same (our) codebase, this is not fixable with external code.

But you forget that hwnd is your window, created by your process, so it is under your control. It means you must design your module to properly restore the chain of window procs. There is no "external code" that can set your window proc to something else.

The emphasis is on "your window."

EDIT

Putting back the WndProc pointer will never affect the chain of window procedures. It is just that after putting it back, your procedure will not be called anymore, but the next one is called directly, which is exactly what you want.