2

No matter what the scenario may be I'm able to recreate this annoying problem 100% of the time. Create a .Net project, C# or VB.Net. Add a ToolStrip control to the form. Create a few simple DropDownButton(s) that contain at least 2 menu items. Add any other controls you wish, a list box (populate it so it can receive focus correctly) and a ComboBox control. Either assign shortcut keys or enable TabStop on the ToolStrip so that it can receive focus by Keyboard.

Run the project (Debug/Release, which ever you fancy). Use your Keyboard to give the ToolStrip Focus (by tab or shortcut key). Arrow down into a sub item. Now select the escape key to collapse the Toolstrip sub menu. Tab to the ListBox or ComboBox that contains a few Items. All looks great right? Now use your arrow keys to navigate in these controls... Surprise! your back on the ToolStrip and the control you thought had focus doesn't!

I've tried multiple things to force focus on the ListBox. One example is I'd add the event handler for OnEnter (ListBox.Enter+=...) and add some code like:

ListBox.Focus();
ListBox.Select();

Nothing was a success... It seems like once the menu expands on a toolstrip you will be forever stuck on this control using your Keyboard... This is important for me to resolve due to the fact that i work with blind users whom use keyboard navigation only... Is this a bug? I cannot reproduce this in MFC...

Any suggestions?

Update I was able to find a control that doesn't reproduce this strangeness...

System.Windows.Forms.MainMenu is the only "Tool Bar object" that doesn't behave like the others...

I'd still like some feedback on the above though (Help for others and myself)...

Update 2 The underlying issue is within [ToolStripObject].TabFocus property... if set to false all seems to work ok... giving focus back to the control that "looks" like it's focused. But having that capability to allow a blind user to navigate throughout all UI controls via tab is a handy thing to implement... it's too bad this property doesn't work like it should....

devHead
  • 794
  • 1
  • 15
  • 38

1 Answers1

2

I got it to work by overriding the ToolStripMenuItem:

public class ToolStripMenuItemEx : ToolStripMenuItem {

  protected override bool ProcessCmdKey(ref Message m, Keys keyData) {
    if (keyData == Keys.Escape) {
      ToolStripDropDownButton tb = this.OwnerItem as ToolStripDropDownButton;
      if (tb != null) {
        tb.HideDropDown();
        return false;
      }
    }
    return base.ProcessCmdKey(ref m, keyData);
  }
}
LarsTech
  • 80,625
  • 14
  • 153
  • 225
  • Hi Lars, I just implemented your sub classed ToolStripMenuItem with the scenario i need posted above (basically need TabStop on) and actually ended up getting trapped on the toolbar once more... are you sure your toolbar object has a TabStop property that's set to true? – devHead Jan 09 '13 at 20:52
  • Closing the menu items isn't part of the issue, they collapse fine when the escape key is pressed in a normal scenario. – devHead Jan 09 '13 at 20:54
  • @Don Yes, my ToolStrip has `TabStop = true` on it. I created a form with the way you described it and saw that the arrow keys basically acted like a Tab key once you tried to escape from a ToolStrip dropped menu. The posted code is the only code in my project and it made it work for me. Closing the menu becomes an issue (or should) if you return true for that function, which is why I manually hide it. – LarsTech Jan 09 '13 at 21:02
  • ahhh...you made a mistake in the code you posted... it returns true if tb != null... i changed it to false and it works... i need to try a few things – devHead Jan 09 '13 at 21:08
  • @Don Hmm, looks like the `tb.HideDropDown();` does the trick. I commented out the `return true;` line and it still worked. – LarsTech Jan 09 '13 at 21:14
  • i removed the return statement and it leaves me stuck... i've tried a few things and only works if return false... – devHead Jan 09 '13 at 21:16
  • @Don Well, it seems harmless, so I put it the way you had it. – LarsTech Jan 09 '13 at 21:19
  • since this looks directly related to a key press process I'm marking your response as the answer, thanks!! – devHead Jan 09 '13 at 21:21