c# - programacion - Excel CustomTaskPane con control WebBrowser: problemas de teclado/enfoque

etiquetas label visual basic

Question

Estoy teniendo este problema exacto https://social.msdn.microsoft.com/Forums/vstudio/en-US/e417e686-032c-4324-b778-fef66c7687cd/excel-customtaskpane-with-webbrowser-control-keyboardfocus-issues? foro = vsto

También se menciona aquí https://connect.microsoft.com/VisualStudio/feedback/details/521465/the-focus-issue-between-excel-cells-and-excel-customtaskpane-with-webbrowser-control

Estoy escribiendo un complemento de Excel 2010 con Visual Studio Professional 2013. He creado un CustomTaskPane simple con un elemento System.Windows.Forms.WebBrowser que lo está archivando. El plugin funciona bien y puedo navegar dentro del navegador web haciendo clic y cambiar el estado de las casillas de verificación.

Cuando hago clic en un cuadro de texto de entrada obtengo el foco y veo que el cursor parpadea, pero cuando empiezo a escribir, el texto se envía a Excel y se escribe en una celda en lugar del cuadro de texto dentro del navegador.

Agrego el panel de tareas personalizado cuando se carga la cinta.

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

Cuando hago clic en el cuadro de texto, presiono F6 que funcione correctamente. El encabezado customtaskpane se oscurece ligeramente y el texto se captura en el cuadro de texto.

¿Cómo puedo solucionar este problema para que cuando haga clic en el cuadro de texto de entrada, el texto entre en el cuadro en lugar de en Excel?

EDITAR: Ok, hice algunas pruebas más. Si agrego eventos en mi TaskPaneView para rastrear el mouse intro y hago clic en ellos funcionan, pero solo si elimino el elemento secundario del navegador web. Lo que significa que el navegador web está bloqueando de alguna manera estos eventos y evitando que TaskPaneView entienda que tiene foco. Si también agregué un control de formulario de texto en TaskPaneView junto al navegador, el cuadro de texto funciona totalmente bien y TaskPaneView entiende que tiene foco y luego el campo de texto de entrada dentro del navegador luego comienza a funcionar. Si llamo al método de enfoque directamente en el navegador web, TaskPaneView entiende que tiene foco y todo funciona perfectamente. Entonces, claramente, el problema no está realmente en el teclado, sino en el hecho de que no se le dice a TaskPaneView que tiene foco cuando se hace clic en el navegador para que las teclas vayan al área equivocada. Si puedo encontrar una manera de hacer que TaskPaneView comprenda, tiene todo el enfoque que debería funcionar.

Answer 1

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

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

Agregué esta función a mi TaskPaneView que es simplemente un UserControl con ese niño webbrowser. 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 verificar si el mensaje es 528, lo que creo que significa notificar a Parent. No sé si este es exactamente el mensaje que debería estar escuchando, pero parece funcionar.

Una vez que tengo el mensaje de mensaje correcto, compruebo si TaskPaneView tiene foco y si no, le doy enfoque con la función focus() . Hice una prueba anterior que mostraba si invoqué el focus manualmente en TaskPaneView, todo funcionó bien. Entonces, si no tengo foco, entonces solicite el enfoque manualmente y todos estamos bien.

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

Answer 2

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

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

No creo que valga la pena pasar más tiempo solucionándolo o averiguando por qué sucede porque ¡ES UN ERROR! Iniciar sesión en un error de Connect para ayudar a Microsoft a solucionarlo es lo mejor que puede hacer. Solo podemos evitarlo, 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 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 fue bombeado al evento Calendars_SelectedChange() . Así que podemos ver un poco de un tema del comportamiento que se forma aquí y que Hans explica bien (Citando de las preguntas y respuestas a las que me he vinculado en mi comentario) :

Lo que nunca es un problema (es decir, a menudo puede ser problemático) es que usted 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 tanto en WPF como en Winforms, tienen su propio bucle 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 utiliza 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 característica anti-malware, Microsoft siempre está preocupado por los programas que juegan con las aplicaciones de Office.

Y no olvide el caso VSTO WPF Connect con menú que no recibe eventos de clic . La solución consistía en utilizar DispatcherFrame para enviar mensajes y suscribirse a GotFocusEvent y LostFocusEvent para el menú.

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