为什么我在 Visual Studio 2005/2008 中失去输入焦点
我为 Visual Studio 2005/2008 编写了一个插件。它将提示一个带有一些编辑控件的窗口作为子窗口。但是如果打开
- 带有文档的VS，然后打开我的Add-In，当
- 没有任何文档的情况下键入Tab/Delete/Backsapace/Ctrl-C等时，那些子编辑控件将失去输入焦点，然后打开我的Add-In，就可以了。
我想我找到了原因。如果我删除VS中的命令绑定，例如命令Edit.InsertTab与Tab绑定，那么当我在我的Add-In中键入Tab时，输入焦点不会丢失。
我尝试用模式对话框替换我的加载项窗口，令我惊讶的是，输入焦点不会丢失。
我想知道为什么。而且我不想使用对话框。任何人都可以告诉我如何解决它。谢谢。
I wrote a Add-In for Visual Studio 2005/2008. It will prompt a window with some edit controls as child windows. But if open VS
- with a document and then open my Add-In, those child edit controls will lose input focus when type Tab/Delete/Backsapace/Ctrl-C etc.
- without any document and then open my Add-In, it is OK.
I think I found the reason. If I delete a command binding in VS, such as the command Edit.InsertTab binding with Tab, then when I type Tab in my Add-In, the input focus will not be lost.
And I tried replace my Add-In window with a modal dialog, it's surprise to me, the input focus will not be lost.
I want to know why. And I don't want to use dialog. Anybody can tell me how to resolve it. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
原因在于 Visual Studio 内部键盘输入的路由方式非常复杂。
Visual Studio 消息循环会将 Windows 消息（不包括字母数字输入）的优先级赋予 Visual Studio 命令。它将调用活动
IVsTextView的IOleCommandTarget链。您提到的键是由编辑器的某些部分专门处理的，因此它们优先，处理消息并导致您的输入失去焦点。解决此问题的方法是将
IOleCommandTarget实例添加到活动视图的IVsTextViewOLE 命令目标链中。当您的窗口处于活动状态时，您可以拦截给定的键，将它们标记为禁用，然后它们将被路由到您的窗口。我很想在这里给出一个小代码片段，但不幸的是没有小代码片段可以充分演示这个解决方案。相反，我将向您介绍在 Visual Studio 的 Vim 模拟器中使用的相同技巧。
The reason why is due to the very complex way that keyboard input is routed inside of Visual Studio.
The Visual Studio message loop will give first priority of windows messages (excluding alpha-numeric input) to Visual Studio commands. It will call into the
IOleCommandTargetchain for the activeIVsTextView. The keys you mentioned are specially handled by parts of the editor and hence they take precedence, handle the message and cause your input to lose focus.The way to get around this is to add an
IOleCommandTargetinstance into theIVsTextViewOLE command target chain for the active view. When your window is active you can intercept the given keys, mark them as disabled and then they will be routed to your window.I'd love to give a small code snippet here but unfortunately there is no small code snippet that adequately demonstrates this solution. Instead I'll point you to the same trick used in my Vim emulator for Visual Studio.