Behavior of a MenuStrip inside the Actions Pane

Behavior of a MenuStrip inside the Actions Pane

• bdagman

  Hi,
  
  Is there any progress regarding this problem Where can we get the fix
  
  Or at least please suggest a workaround. This is a very annoying problem. I don't imagine a tree/list view without a context menu strip and neither I do imagine a context menu that never hides!
  
  I tried to hook up various events fired by the context menu strip, such as Leave, Closing, LostFocus but they are never fired, because the menu strip doesn't ever get the keyboard focus. I even tried to call Select() and Focus() explicitly on Opened, then the actions pane loses focus, but keyboard arrows still don't work in the menu, and it still doesn't hide. Also, I tried to turn AutoClose property to false, but it has no effec.
  
  It all looks like a bug with keyboard/focus dispatching around word editor window, actions pane etc.
  
  Please help!
  
  

• Mike Whyte

  So Reza Chisaz (Microsoft) states within this forum question that this is a bug. Has any progress been made, or any other documentation I can get on this I am having the same issue. Thanks you.

  David

  
  

• Jens Stjarna

  I am experiencing this same problem with popup menus staying up in the ActionsPane even when the mouse has moved away to a totally different place. Is there any status on if/when this bug will be fixed Also is there a workaround Thanks!
  

• Hans Guan

  Hi Oleg

  <<Hey, anybody there
  
  It's still very important and urgent! I've also found that dropdown button menus stick in the same manner as context menu strips :(
  >>

  Posting in a thread marked as "Answered" isn't a good way to follow-up on something like this. Low visibility :-) Better would be to post a new question with a link back to the original thread.

  
  
  

• azunaro

  Oleg (and others),
  
  I got around this undesired behavior on my user control by implementing handlers for control.Leave and control.MouseDown. Handling Leave allows the menu to disappear when you switch amongst multiple controls (i.e., the default behavior in a stand-alone WinForms app) or between your user control and the Word document. Handling MouseDown allows the menu to be removed on subsequent left-clicks to the control. Here's an example where treeView1 has contextMenuStrip1 assigned to its ContextMenuStrip property:
  
  private void treeView1_Leave(object sender, EventArgs e)
  {
      this.contextMenuStrip1.Hide();
  }
  
  private void treeView1_MouseDown(object sender, MouseEventArgs e)
  {
      if (e.Button.Equals(MouseButtons.Left))
      {
          this.contextMenuStrip1.Hide();
      }
  }
  
  This still does not cover the case of controls (such as panels or disabled controls) which do not pull focus away from the treeview by default on click. You will likely need to add additional control.MouseDown handlers to these controls if you want clicks outside of your treeview to result in the removal of the contextMenuStrip.
  
  The only remaining nit is that there is a border area around the ActionsPane on screen which is still in .NET land, not in Word land, so clicking there does not result in Leave or MouseDown firing on your user control or its children. Maybe the VSTO team could enlighten us as to what this area corresponds, and whether we could use a similar technique to what I've outlined here to handle those clicks. Again, it's a minor nit, and I doubt if my users will notice or complain.
  
  Jesse
  
  

• mk8086

  Hey, anybody there
  
  It's still very important and urgent! I've also found that dropdown button menus stick in the same manner as context menu strips :(
  
  

• Michael Feingold

  This is a bug that we'll need to consider fixing in our next release. I've logged this issue in our bug database.

  Thanks

  
  
  

• Ljubica

  Reza, Based on my observations and analysis, I had arrived at the conclusion that it was a bug.  I will have to create an alternative solution. Thanks for letting me know.

  Chuck Hartman

  
  

• Brian.Webb

  Thanks, JesseJ, but sorry, your solution is too dirty, because a) it breaks encapsulation badly - all controls on the actions pane should be aware of the buggy context menu and of each other, and b) there will still be cases when the damned menu will stick.
  
  Blame, blame, blame Microsoft, I have spent DAYS trying to fix the problem... Here are my results.
  
  Menus stick due to keyboard focus and navigation problems/ambiguities in Word itself. I experimented with context menu and toolstrip dropdown menu. I've noticed that the menu works perfectly OK when the task pane is not "active", i.e. its header is not highlighted. For example, if you click inside the document editor before clicking on the dropdown button, the menu works perfectly OK, including the keyboard keys in the menu. Else if you click on the tree view first, the task pane becomes active and both drop down and context menu begin to stick.
  
  I tried to fool Word and did SendKeys.Send() with F6 or Ctrl+Tab on menu opening, in order to deactivate the Task pane. You'd agree this is a tempting idea, and it did work, but unfortunately not in all cases, because Word does not provide much control on what pane is currently active. Additionally, after this trick Word sometimes falls into an ill state when all menus fail to open at all.
  
  So my final workaround is to use mouse capture. When the menu is Opened, I set forcedly menu.Capture = true, and then monitor MouseDown and MouseCaptureChanged events, where I do menu.Hide(). For dropdown menu, I had to create additional workarounds to make the dropdown button behave normally. The drawbacks of my solution are: 1) keyboard keys still don't work in open menus, 2) multi-level menus are not supported - maybe I could do it but yet don't need to, and 3) damn, it should have worked without all this! (blame Microsoft again) :)
  
  

• VishalR

  Did you resolve this issue Just curious as there has been no activity in this thread since 10/15/05. If we don't hear from you within a week, we'll consider this a closed matter.

  Thanks!

  Mike Hernandez
  Community Program Manager
  VSTO Team

  
  

• newuseroverhere

  Hum... for what I know, there are no reasons that you context menu stay on top...
  
  Have you try to refresh your treeview after the click event
  
  
  HTH.
  
  
  Bye.
  
  
• Behavior of a MenuStrip inside the Actions Pane