Windows mobile 使用RegistryNotifyCallback与RegistryNotifyWindow的结果不一致

（我在WM 6.5上）

在监视注册表的某些部分时，我开始使用

：：RegistryNotifyCallback

，但注意到一些应该到达的通知从未到达。我切换到

：：RegistryNotifyWindow

，丢失的通知如期到达。我不记得重新编程的步骤了，因为那是很久以前的事了，但现在由于其他原因我不得不回到回调版本[1]，我想在可能的情况下消除最初的疑虑

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

• 这两个消息是否有可能/可能会起到不同的作用？我假设回调和发布的窗口消息具有相同的源代码分支，我甚至设想

  RegistryNotifyWindow

  是通过WM core中的

  RegistryNotifyCallback

  实现的，因此，调用回调或发布消息之间的决定是一个非常晚的活动（在CE/WM状态和notification broker核心中），而MS方面的一个bug似乎很蹩脚

---

[1] 存在一种竞争条件，有时会导致在将更改实际持久化/刷新到注册表之前通知某些注册表更改，因此在收到通知时读取该值会给出错误的结果。但是，回调数据参数和窗口消息的WPARAM提供的“新值”实际上是尚未刷新到注册表的正确值。由于

：：RegistryNotifyWindow

只提供DWORD值，而我需要字符串和二进制值，因此我必须更改为

：：RegistryNotifyCallback

，它可以正确处理所有注册表值数据类型（我不想

：：睡眠

，以确保状态和通知代理刷新这些值）

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

我发现：：RegistryNotifyCallback和：：RegistryNotifyMsgQueue对于REG_DWORD都不可靠，但REG_SZ没有问题。奇怪的是，REG_DWORDs有时确实可以工作，比如我手动编辑注册表值，但是当从另一个程序发送批处理a通知时，某些通知不会触发