查找由RegisterWindowMessage Windows API获得的消息的原始名称 [英] Find original name of a message obtained by RegisterWindowMessage Windows API
问题描述
在调试应用程序以提高性能时，我发现它在处理大于0xC000的消息时浪费了时间.这显然是由 RegisterWindowMessage API创建的消息.但是，该应用程序使用了两百多条这样的消息.有没有办法通过消息的数值来查找消息的原始名称?
While debugging the application in an attempt to improve performance, I found that it loses time in processing a message that is greater then 0xC000. This is obviously a message created by the RegisterWindowMessage API. However, the application uses more than two hundreds such messages; is there a way to find the original name of the message by its numerical value?
GetAtomName 和 GlobalGetAtomName 失败，
ERROR_INVALID_HANDLE
ERROR_INVALID_HANDLE
错误.
推荐答案
没有用于获取已注册窗口消息名称的 official API.
话虽这么说， RegisterWindowMessage()和 RegisterClipboardFormat()恰好当前共享一个原子表(以及其他一些API)函数)，因此在Windows的当前版本中，您可以使用 GetClipboardFormatName() 以获得注册的窗口消息的名称.
There is no official API to get the name of a registered window message.
That being said, RegisterWindowMessage() and RegisterClipboardFormat() happen to currently share a single atom table (along with a few other API functions), so in current version of Windows, you can use GetClipboardFormatName() to get the name of a registered window message.
在Raymond Chen在MSDN上的博客中对此进行了描述:
This is described on Raymond Chen's blog on MSDN:
如何调查大量泄漏窗口的可能性类(RegisterClass)?
碰巧的是，在当前版本的Windows中，注册的类名称，注册的剪贴板格式名称和注册的窗口消息名称都来自同一个原子表.我想重申一下，这是实施细节，它可以随时更改，因此请不要依赖于此.我提供这些信息用于诊断目的，这就是我们在这里拥有的.
It so happens that in current versions of Windows, registered class names, registered clipboard format names, and registered window message names all come from the same atom table. I wish to reiterate that this is an implementation detail which can change at any time, so don't take any dependencies on this. I provide this information for diagnostic purposes, which is what we have here.
客户一旦遇到问题就可以这样做:
The customer can do this once they encounter the problem:
Foreach atom in (0xC000 .. 0xFFFF)
If (GetClipboardFormatName(atom, buffer, bufferSize))
Print buffer
这将打印出所有类的名称，剪贴板格式和已注册的窗口消息.原子表中有16384个原子的空间，实际上，空间不超过100个左右，因此，如果看到15,000个以上的条目，那是泄漏类的一个很好的信号.
This will print out the names of all the classes, clipboard formats, and registered window messages. There is room in the atom table for 16,384 atoms, and in practice there aren't more than a hundred or so, so if you see more than 15,000 entries, that's a really good sign that you're leaking classes.
我将从RegisterWindowMessage函数创建的注册窗口消息开始.这些不是正式原子；它们就像原子一样，恰好位于0xC000到0xFFFF范围内的整数.但是，是的，在内部，它们是原子.当然，您不应该依赖它，因为它不是契约性的.认为这是一个奇妙的巧合.
I'll start with registered window messages, created by the RegisterWindowMessage function. These are not officially atoms; they are just integers that happen to lie in the range 0xC000 to 0xFFFF, just like atoms. But yeah, internally, they're atoms. Of course, you shouldn't rely on it since it's not contractual. Think of it as a fantastic coincidence.
由RegisterClipboardFormat消息创建的已注册剪贴板格式也不是正式原子；他们只是UINT.甚至没有指定已注册剪贴板格式的数字范围.他们在0xC000范围内闲逛只是实施细节.某天，已注册的剪贴板格式可能具有0x1234之类的值，谁知道.
Registered clipboard formats created by the RegisterClipboardFormat message are also not officially atoms; they're just UINTs. The numeric range for registered clipboard formats isn't even specified; that they hang out in the 0xC000 range is just an implementation detail. Someday, registered clipboard formats may have values like 0x1234, who knows.
因此，正如我所说，目前没有没有官方API 来获取已注册窗口消息的名称，但是您可以当前通过处理已注册窗口消息来解决该问题.窗口消息与注册的剪贴板格式相同.但是，如果 RegisterWindowMessage()的实现发生变化，将来以这种方式使用 GetClipboardFormatName() MAY 可能会中断.
So, as I said, there is currently NO OFFICIAL API to get the name of a registered window message, but you can currently get around that by treating a registered window message the same as a registered clipboard format. But using GetClipboardFormatName() in this manner MAY break in the future if the implementation of RegisterWindowMessage() ever changes.
这篇关于查找由RegisterWindowMessage Windows API获得的消息的原始名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
