Window.NextTab and Window.PreviousTab keybindings do not work on Form Designer tabs. by Greg Bray

This will be fixed in the next Visual Studio release. The Window.NextTab and Window.PreviousTab commands will be implemented to work in a consistent way for both toolwindows and documents.

Thank you for reporting this issue,
Alin Constantin
[VS Pro Development]

Thanks for the great write-up of the problem! I actually end up setting the left sweep and right sweep of the scroll wheel of my mouse to Ctrl+Tab and Ctrl+Shift+Tab so that I can quickly switch between tabs/documents in multiple programs, so for me at least the best solution would be if Window.NextTab worked with all window types and could be bound to the standard Tab shortcut keys. Right now I use a macro (see workarounds tab above) and it works reasonably well, but after searching around it sounds like there are many others that would like non-MRU tab switching too. Adding this to the next release of Visual Studio or as an option in the Visual Studio 2010 Productivity Power Tools would be greatly appreciated.

Thanks again for the response, and keep up the great work!

Thank you for reporting this issue. This is actually "By design" for Visual Studio 2010.

The Window.NextTab and Window.PreviousTab keybindings don't work currently on FormDesiger tabs because they are not supposed to. These commands are specific to toolwindows in a tab group (e.g. SolutionExplorer/TeamExplorer/ClassView) and they activate the previous/next toolwindow in the tab group.

If you try the same scenario in Visual Studio 2008 or older you'll see the Ctrl+Tab bound to Window.NextTab doesn't work even for simple text documents.

In Visual Studio 2010, Ctrl+Tab bound to Window.NextTab changes the active tab when the active document is a text editor, but not because it's bound to Window.NextTab.
When Ctrl+Tab is pressed in a txt editor, the key is not translated to any of the keybindings (and it's not translated to Window.NextTab either because the active window is not a toolwindow in a tab group). The WM_KEYDOWN message sent by Windows to the main window is passed to WPF and it used WPF-style events for keybinding that start with the editor and bubble up the visual tree. Since the editor in VS10 is fully implemented as a WPF-window with no intervening HWNDs, the keydown events reach eventually the TabControl of the document well area, where WPF uses Ctrl-Tab to switch the active view in the tab control. This is the default key treatment of the WPF System.Windows.Controls.TabControl, so the fact that your scenario worked in VS10 for text documents is merely due to a fortunate implementation detail.

Other editors (like the Winforms designer, or even text-based editors like the BinaryEditor) are not implemented using WPF control. Pressing key combinations in such editors generate WM_KEYDOWN events that are sent to the editor window, and it's up to the editor to do whatever they want with it. E.g. The Binary Editor will move focus between the hexadecimal and ASCII display zones when Ctrl+Tab/Ctrl+Shift+Tab is pressed. The keys never reach the WPF main window, they are not translated to WPF-style events and the TabControl doesn't get to change the active tab.

That being said, we agree this design of having Window.NextTab and Window.PreviousTab specific to toolwindows is not ideal. Nothing in the commands names suggest these commands work only in a toolwindow.
We also realize the need of being able to switch document tabs in an order that's not MRU-dependent.

We don't see any reason why Window.NextTab and Window.PreviousTab commands can't be reused to work for document windows, too, so we will change this design in next Visual Studio version, and allow the Window.Previous/NextTab commands to change the active tab in both documents and toolwindows.

Thank you,
Alin Constantin
[Visual Studio Pro development]

Thank you for reporting the issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)