Excel CustomTaskPane with WebBrowser control - keyboard/focus issues

Question

I am having this exact issue https://social.msdn.microsoft.com/Forums/vstudio/en-US/e417e686-032c-4324-b778-fef66c7687cd/excel-customtaskpane-with-webbrowser-control-keyboardfocus-issues?forum=vsto

Also mentioned here https://connect.microsoft.com/VisualStudio/feedback/details/521465/the-focus-issue-between-excel-cells-and-excel-customtaskpane-with-webbrowser-control

I am writing an Excel 2010 plugin using Visual Studio Professional 2013. I've created a simple CustomTaskPane with a System.Windows.Forms.WebBrowser child filing it. The plugin works just fine and I am able to navigate inside the webbrowser by click and change the state of checkboxes.

When I click on an input textbox I get focus and I see the cursor blinking, but when I start typing the text is sent to Excel and written into a cell instead of the textbox inside the browser.

I add the custom taskpane when the ribbon loads.

private void Ribbon_Load(object sender, RibbonUIEventArgs e)
{
  TaskPaneView taskPaneView = new TaskPaneView();
  Microsoft.Office.Tools.CustomTaskPane myTaskPane = Globals.ThisAddIn.CustomTaskPanes.Add(taskPaneView, "Title");
  myTaskPane.Visible = true;
}

When I click on the textbox then hit F6 it works correctly. The customtaskpane header darkens slightly and text is captured in the textbox.

How can i fix this issue so that when I click on the input textbox the text goes into the box instead of Excel?

EDIT: Ok, I did some more testing. If I add events on my TaskPaneView to track mouse enter and click they work, but only if I remove the web browser child. Meaning the web browser is somehow blocking these events and preventing the TaskPaneView from understanding it has focus. If I also added a textbox form control into the TaskPaneView along side the browser, the textbox works totally fine and the TaskPaneView understands it has focus and then the input text field inside the browser then starts works. If I call the focus method directly on the web browser, the TaskPaneView understands it has focus and everything works perfectly. So clearly the issue isn't really with the keyboard, but instead an issue of the TaskPaneView not being told it has focus when the browser is clicked on so the keystrokes go to the wrong area. If I can find a way to make TaskPaneView understand it has focus everythign should work.

Answer 1

Ok I was able to fix the issue using the following code

protected override void WndProc(ref Message m)
{
  const int WM_PARENTNOTIFY = 528;
  if(m.Msg == WM_PARENTNOTIFY && !this.Focused)
  {
    this.Focus();
  }
  base.WndProc(ref m);
}

I added this function to my TaskPaneView which is simply a UserControl with that webbrowser child. I don't have a deep understanding of why or how this works, but basically I think what's happening is i'm intercepting WndProc which is some low-level function that process messages sent to the window. I use it to check to see if the message is 528, which I think means notifyParent. I don't know if this is exactly which message I should be listening for, but it seems to work.

Once I have the right message message I check to see if the TaskPaneView has focus and if not, I give it focus with the focus() function. I did testing earlier that showed if I manually invoked focus on the TaskPaneView everything worked fine. So if I don't have focus, then manually request focus and we are all good.

I would appreciate it if someone can provide a more detailed explaination as to why this works so I can understand it better, but at least I solved the problem. Thanks Jeremy Thompson for getting me thinking about this issue in a new way.

Answer 2

Q: Provide a more detailed explanation as to why this works so I can understand it better

Glad you got it working! To perform a root cause analysis we'd need to see where that 528 message gets sent and we'd need the Microsoft Excel source code to do that.

I don't think its worth spending anymore time troubleshooting it or working out why it happens because IT IS A BUG! Logging a Connect bug to help Microsoft fix it is the best thing you can do. We can only work around it, it's a problem in their source code.

It is quite rare you find these scenario's in VSTO to see bugs and you've certainly found one; where a user enters text input into an Add-Ins textbox and the message flows into a cell in the worksheet!! In my situation; where the message wasn't pumped to the Calendars_SelectedChange() event. So we can see a bit of a theme of the behavior forming here that Hans explains well (Quoting from the Q&A I linked to in my comment):

What's never not a problem (ie can often be problematic) is that you rely on the message pump in Excel to dispatch Windows messages, the messages that make these controls respond to input. This goes wrong in WPF as much as Winforms, they have their own dispatch loop that filters messages before they are delivered to the window. Key things that go wrong when their respective dispatcher isn't used are stuff like tabbing and short-cut keystrokes.

And then some, this kind of problem would be induced by Excel doing its own filtering before dispatching messages. I'd guess at an anti-malware feature, Microsoft is forever worried about programs messing with Office apps.

And dont forget the VSTO WPF Connect case with menu's not receiving click events. The workaround involved using the DispatcherFrame to pump messages and subscribe to GotFocusEvent and LostFocusEvent for the menu.

So the bug is to do with controls that respond to input and the void WndProc(ref Message m) messages being incorrectly filtered or redirected in the dispatch loop.