3

我的自定义 Windows shell 上下文菜单处理程序就像一个魅力，适用于从 XP 到 7 的所有 Windows 版本，但在 Windows 8、8.1 和 10 上，安装它会破坏Win+X菜单（有时称为“高级用户菜单”或“快速访问菜单"或"WinX menu"）：当点击Win+时X，菜单按预期显示，但它的项目不再起作用（当我点击它们时没有任何反应），除了底部的最后四个项目仍然作为预期（“搜索”、“运行”、“关闭/退出”、“桌面”）：

高级用户菜单

我很快在 Google 上发现，对于大量与 Windows 8/10不“兼容”的 shell 扩展来说，这是一个众所周知的问题。但遗憾的是，我只发现应用程序用户在谈论这个问题及其“解决方案”，而没有开发人员谈论这个。而这些用户提出的两个“解决方案”是：

  1. 取消注册这个 shell 扩展
  2. 卸载注册此 shell 扩展的应用程序（导致解决方案 1...）

例如，请参阅this、this或this以阅读人们谈论此问题的信息。

注意：我的外壳扩展名适用于*文件类型，即所有文件。

几天后，我在shell扩展源代码中找到了这个问题的原因，所以我认为它可以帮助其他开发人员在StackOverflow上分享它，作为一个自我回答的问题（我没有找到这个问题）。见上面的答案。

4

1 回答 1

1

我首先查看了微软提供的shell扩展示例代码（不会导致这个问题），将其与我的代码进行比较，并逐步将我的部分代码替换为微软的代码，并在每次替换后对其进行测试。

我发现阻止高级用户菜单工作的是你在接口方法InvokeCommand()中返回的内容IContextMenu：如果你的扩展不能处理给定的动词，它应该总是返回E_FAIL，以便 Windows 尝试其他实现IContextMenu（有关更多详细信息，请参阅Microsoft 文档） . 似乎当单击高级用户菜单项时，Windows首先调用了我的扩展名（*文件类型），然后由于它没有返回E_FAIL这个未知动词，Windows认为我的shell扩展名已经处理了这个事件，所以它没有t 通过名义上的超级用户菜单回调处理它。

顺便说一句，我觉得三件事很奇怪：

  1. 为什么 Windows 甚至会尝试使用 shell 文件扩展名来处理这个高级用户菜单事件？此菜单是否使用与任何其他资源管理器的文件上下文菜单相同的设计/机制进行编码？

  2. 为什么这个错误还没有产生更多的副作用？我的意思是这应该从一开始就破坏了整个 shell 扩展系统，不是吗？

  3. 为什么这么多应用程序有这个错误？（这意味着为什么这么多应用程序没有E_FAIL按预期返回？）。写这段代码已经有一段时间了，我真的不记得它来自哪里，但我猜它来自 Microsoft 示例或任何 Microsoft 员工教程（太面向 Microsoft，无法自己编写代码） . 如果是这样，那可能会回答为什么这么多 shell 扩展会导致这个问题的问题......

如果有人对此主题有一些想法可以分享，我会很感兴趣！顺便说一句，我希望我的帖子可以帮助其他开发者。在查看新的 Microsoft 示例时，我首先害怕必须从他们的示例中重写我所有的 shell 扩展，而不知道我的代码有什么问题！

于 2015-02-07T19:54:32.550 回答