关于GWLP_WNDPROC的那些奇怪的返回值

关于魔法数字

我们可以使用如下的方法来获取窗口当前使用的窗口过程。

兼容32位和64位Windows版本:GetWindowLongPtr(hwnd, GWLP_WNDPROC)仅在32位Windows下使用:GetWindowLong(hwnd, GWL_WNDPROC)

为什么有时候我们会得到一些比较奇怪的返回值呢?如果窗口当前使用的窗口过程和GetWindowLongPtr的调用者不兼容,则GetWindowLongPtr调用将不会返回真实的窗口过程地址,而是返回一个所谓的”魔法数字”。

这个魔法数字的唯一目的在于,它可以被CallWindowProc识别并被转换成窗口过程所接受的参数格式。

举个例子

如果你使用的是Windows XP,并且系统是UNICODE版本的,但是有一个组件使用了ANSI来进行编译并在代码中调用了GetWindowLong(hwnd, GWL_WNDPROC)。因为调用者使用的是ANSI版本的消息,而窗口过程希望收到的是一个UNICODE版本的消息,所以这个调用将不会返回真实的窗口过程地址,而是返回一个上面所提到的魔法数字。

当你将这个魔法数字传递给CallWindowProc后,它会识别这个魔法数字:”噢,我需要将消息从ANSI版本转换为UNICODE版本,然后将UNICODE版的消息传递给窗口过程”。

另一个例子

如果你使用的系统是Windows 95且窗口是由一个32位组件所创建的,但是调用GetWindowLong(hwnd, GWLP_WNDPROC)的是一个16位的组件。再一次的,32位的窗口过程不会被真正的返回,因为消息需要从16位转换为32位。(另外,一个16位的程序不能跳转到一个32位的地址空间)

所以,GetWindowLong再一次地返回了一个魔法数字给调用者,CallWindowProc会识别这个魔法数字:”噢,我需要将16位版本的消息转换为32位版本的,然后将转换后的消息传递给窗口过程”。(实际上,我们使用了术语thunks来指代转换这个操作)

总结

你从GetWindowLongPtr(hwnd, GWLP_WNDPROC)调用中获取到的返回值,只应该有两个去处:

1) 将返回值传递给CallWindowProc。

2) 将返回值传递给SetWindowLongPtr(hwnd, GWLP_WNDPROC)。

猜你喜欢

转载自blog.csdn.net/mmxida/article/details/107876348