`Ctrl` with `Tab`/`Shift`+`Tab` should work in `ToolStrip`

[ArtemTatarinov]

• Ctrl+Tab should move button focus forward inside ToolStrip when TabStop is false
• Ctrl+Shift+Tab should move button focus backward inside ToolStrip

This is a problem. Ctrl+Tab should move "forward", Ctrl+Shift+Tab should move backwards . Try office toolstrips. Consider a user who navigates office with one set of keys, even unintentionally, and a winforms app with another. Sounds like an annoying experience. I always want to hit f12 to go to source in GH web UI for example. Even worse if office ever works with Core plugins....

_Originally posted by @Tanya-Solyanik in https://github.com/dotnet/winforms/pull/5726#discussion_r706427053_

[weltkante]

The implementation should be done in a way that its possible to opt-out of this behavior if the application wants to give this shortcut a different meaning yet still have toolbars. Some multi-document applications prefer to switch documents with those shortcuts.

[ArtemTatarinov]

It's possible to use Ctrl for moving ToolStrip button focus forward and backward with rather simple modification.

ProcessDialogKey method at ToolStrip class

Before the fix:

bool hasModifiers = ((keyData & (Keys.Alt | Keys.Control)) != Keys.None);
...
case Keys.Tab:
    // ctrl+tab does nothing
    if (!hasModifiers)
    {
        retVal = ProcessTabKey((keyData & Keys.Shift) == Keys.None);
    }

After the fix:

case Keys.Tab:
    if ((keyData & Keys.Alt) == Keys.None)
    {
       retVal = ProcessTabKey((keyData & Keys.Shift) == Keys.None);
    }

• hasModifiers is used at other switch cases, so we couldn't get rid of it completely

• All Alt+Tab/Alt+Ctrl+Tab/Alt+Shift+Tab/Alt+Ctrl+Shift+Tab combinations are intercepted by Windows, but we can be cautious and make an additional check for Alt not being pressed here.

• ProcessDialogKey method is virtual, so the custom application could override it and use its own Tab press handling. In addition to the fact that focus moving between the ToolStrip buttons occurs only if its TabStop is false and we already have focus at some of the ToolBar buttons (like ToolStripTextBox, for example), maybe it would sufficient for possible opting-out of moving focus with Ctrl+Tab?

[weltkante]

ProcessDialogKey method is virtual, so the custom application could override it and use its own Tab press handling.

Thats not sufficient, you also need everything the original implementation called being public, which it apparently isn't. For example the implementation is calling Parent.ProcessDialogKey(keyData) which I think is not possible without doing reflection. You lose the ability to process Ctrl+Tab in a central place.

[ArtemTatarinov]

@weltkante, thank you for your answer!

@Tanya-Solyanik, could you please tell what's your opinion on this topic?

[NikitaSemenovAkvelon]

It works correctly if I don't misunderstand a problem. Ctrl+Tab shortcut moves focus to next ToolStrip and with Shift moves to previous one.

@Olina-Zhang could you test it, please? @dreddy-work, @merriemcgaw what do you think if we close this issue as not reproducing?

[dreddy-work]

@NikitaSemenovAkvelon , did you hit same code path that was in the comment here ?

[merriemcgaw]

@Tanya-Solyanik what are your thoughts on this one? The behavior looks reasonable to me but I don't have a full understanding of what you were trying to get done in the original comment.

[Tanya-Solyanik]

@merriemcgaw - in office ribbon Ctrl+Tab moves focus to the next item in the current toolstrip, not to the next toolsstrip.

[Olina-Zhang]

@Olina-Zhang could you test it, please?

@NikitaSemenovAkvelon I have the same testing result as you: Ctrl+Tab move focus between ToolStips, Tab moves focus in ToolStrip. And Tanya has given the comment: when TabStop is false, Ctrl+Tabshould move button focus forward inside ToolStrip, instead of between ToolStrips.

[NikitaSemenovAkvelon]

I've completed a small research about behavior of tabbing in few apps. There are some differences: 1) Office: Behavior of tab doesn't depend on ctrl modicator. But an important detail is that panel is not a ToolStrip but just a Group. You can see it in Inspect screen. 2) Visual Studio: Behavior of tab depends on ctrl modicator. And panel is a ToolBar. 3) WinForms application: First pair of panels has TabStop = false, second pair has TabStop = true. Behavior of the first pair is the same as Visual Studio, moreover type of panels is the same too. Second pair works differently: pressing Tab switches panels, but pressing Ctrl+Tab does nothing. I've done all of them because I not completely understand what wrong with current behavior. For me it looks correctly. What do you think about this behavior in comparing with Office and VisualStudio, taking into account difference of controls?

[merriemcgaw]

It looks OK to me too. @Tanya-Solyanik, given that these are ToolStrips rather than Ribbons, my thought is that we should be closer to the behavior in VS. What are your thoughts?

[Tanya-Solyanik]

@NikitaSemenovAkvelon, @merriemcgaw , @Olina-Zhang -
Well, Office is the standard in accessibility. VS usage is miniscule compared to office's 😄 . So I would rather copy Office's experience. But this issue overall is a minor one because the user is not stuck within the control either way, there is always a way to exit it. And I can see than Ctrl+Tab is a convenience when user wants to skip the toolstrip altogether. So I will not insist here.

[merriemcgaw]

The behavior of Tabbing through ToolStripContainers has always been a mystery to me 😆. I think we're in an OK place here, and that we've got better places to invest our time in 😉 . Until we find out that the current behavior is a MAS violation, I think we can close this issue.