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 dialo开发者_JAVA技巧g, 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.
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 IOleCommandTarget
chain for the active IVsTextView
. 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 IOleCommandTarget
instance into the IVsTextView
OLE 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.
- http://github.com/jaredpar/VsVim/blob/master/VsVim/VsCommandFilter.cs
精彩评论