Ok, pude solucionar el problema usando el siguiente código

 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); }

Agregué esta función a mi TaskPaneView, que es simplemente un UserControl con ese navegador web secundario. No tengo una comprensión profunda de por qué o cómo funciona esto, pero básicamente creo que lo que sucede es que estoy interceptando WndProc, que es una función de bajo nivel que procesa los mensajes enviados a la ventana. Lo uso para comprobar si el mensaje es 528, que creo que significa notificar a los padres. No sé si este es exactamente el mensaje que debo escuchar, pero parece funcionar.

Una vez que tengo el mensaje de mensaje correcto, verifico si TaskPaneView tiene el foco y, si no, lo enfoco con la función focus() . Hice pruebas anteriormente que mostraban que si invocaba manualmente el focus en TaskPaneView, todo funcionaba bien. Entonces, si no tengo enfoque, entonces solicito enfoque manualmente y todos estamos bien.

Agradecería si alguien puede proporcionar una explicación más detallada de por qué esto funciona para que pueda entenderlo mejor, pero al menos resolví el problema. Gracias Jeremy Thompson por hacerme pensar sobre este tema de una manera nueva.

P: Proporcione una explicación más detallada de por qué esto funciona para que pueda entenderlo mejor.

¡Me alegro de que lo hayas hecho funcionar! Para realizar un análisis de causa raíz, necesitaríamos ver dónde se envía ese mensaje 528 y necesitaríamos el código fuente de Microsoft Excel para hacerlo.

No creo que valga la pena dedicar más tiempo a solucionarlo o averiguar por qué sucede porque ¡ES UN ERROR! Registrar un error de Connect para ayudar a Microsoft a solucionarlo es lo mejor que puede hacer. Solo podemos solucionarlo, es un problema en su código fuente.

Es bastante raro que encuentre estos escenarios en VSTO para ver errores y ciertamente ha encontrado uno; donde un usuario ingresa la entrada de texto en un cuadro de texto de Complementos y el mensaje fluye a una celda en la hoja de trabajo. En mi situación; donde el mensaje no se envió al evento Calendars_SelectedChange() . Entonces podemos ver un poco de un tema del comportamiento que se forma aquí que Hans explica bien (Citando de las preguntas y respuestas a las que me vinculé en mi comentario) :

Lo que nunca deja de ser un problema (es decir, a menudo puede ser problemático) es que confía en la bomba de mensajes en Excel para enviar mensajes de Windows, los mensajes que hacen que estos controles respondan a la entrada. Esto funciona mal tanto en WPF como en Winforms, tienen su propio ciclo de envío que filtra los mensajes antes de que se envíen a la ventana. Las cosas clave que salen mal cuando no se usa su despachador respectivo son cosas como tabulación y atajos de teclado .

Y luego, este tipo de problema sería inducido por Excel haciendo su propio filtrado antes de enviar mensajes. Supongo que en una función antimalware, Microsoft siempre está preocupado por los programas que interfieren con las aplicaciones de Office.

Y no olvide el caso de VSTO WPF Connect con el menú que no recibe eventos de clic . La solución implicó el uso de DispatcherFrame para bombear mensajes y suscribirse a GotFocusEvent y LostFocusEvent para el menú.

Entonces, el error tiene que ver con los controles que responden a la entrada y los void WndProc(ref Message m) se filtran o redirigen incorrectamente en el ciclo de envío.