使用RegistryNotifyCallback与RegistryNotifyWindow的结果不一致

Question

（我在WM 6.5上）

我在监视注册表的某些部分时开始使用::RegistryNotifyCallback，但发现一些应该到达的通知从未发生过。我切换到::RegistryNotifyWindow，丢失的通知按预期到达。我不记得repro步骤，因为它已经有一段时间了，但现在我被迫回到其他原因的回调版本[1]，我想在可能的情况下解决最初的疑问。

• 是否有人注意到回调和窗口消息版本之间存在“成功差异”？

• 这两者的功能是否可能不同？我认为回调和发布的窗口消息都具有相同的原始代码 - 分支方式，我甚至可以想象RegistryNotifyWindow是通过WM核心中的RegistryNotifyCallback实现的，因此调用回调或发布消息之间的决定是一个非常晚的活动（在CE / WM状态和通知代理核心中）和MS方面的一个漏洞看起来很蹩脚......

[1]有一种竞争条件有时会导致在更改实际持久/刷新到注册表之前通知某些注册表更改，因此在获取通知时读取值会产生错误的结果。但是，回调数据参数和窗口消息的WPARAM提供的“新值”确实是尚未刷新到注册表的正确值。由于::RegistryNotifyWindow仅提供DWORD值，并且我需要字符串和二进制值，因此我必须更改为::RegistryNotifyCallback，这会正确处理所有注册表值数据类型（我不希望::Sleep第二，以确保状态和通知代理刷新值

Answer 1

我发现:: RegistryNotifyCallback和:: RegistryNotifyMsgQueue对于REG_DWORD都不可靠，但REG_SZ没问题。奇怪的是，REG_DWORD有时会工作，就像我手动编辑注册表值一样，但是当批量通知从另一个程序发送时，某些通知不会触发。

Answer 2

经过一周多的测试，我得出结论，回调版本至少与窗口消息发布版本一样稳定，但由于完全处理所有注册表值类型而不仅仅是REG_DWORD，而且还有更多功能。字符串和二进制。因此，我建议使用回调版本，但必须手动将数据编组到UI线程。