views:

15

answers:

1

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

  1. 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.
  2. 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.

+1  A: 

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.

JaredPar
Thanks very much. Wow, you are the author of VsVim. I'm a newbie to Windows programming. And, could you tell me why there is not the problem with the modal dialog.
Cook Schelling
@Cook, truthfully I don't understand deeply why the modal dialog is not a problem. It's likely either because Visual Studio special cases input when a modal dialog is active (it does that for some cases) or that the message is simply routed into the modal dialog's message loop and Visual Studio's main message loop doesn't see it. My bet is on the former though.
JaredPar