delphi - funciona - El menú contextual desaparece con la automatización de Word
problema menu contextual windows 10 (3)
Cuando estoy editando un documento de Word en un OleContainer (in situ) y cambio a otro documento de Word y luego vuelvo a cambiar, ya no puedo usar el botón de mi derecha. El menú contextual no aparecerá.
Esto sucede en Word 2000, no en Word 2007 (no conozco otras versiones).
¿Cómo puedo deshacerme de este comportamiento?
Como reproducirse
- Crear una nueva aplicación VCL
- Añadir una barra de menú
- Agregue un TOleContainer, Align alClient, AllowInPlace y AllowActiveDoc True.
- Con el TOleContainer, inserte un documento de Word 97-2003
- Agregue un menú ''Cerrar'' a la barra de menú, en su controlador de eventos, agregue
OleContainer1.DestroyObject, para que pueda dejar de editar - Ejecute esta aplicación, haga doble clic en OleContainer para que entre en modo de edición
- Ahora abre Word 2000
- Vuelva a la aplicación, el menú contextual ya no funcionará.
Edición: reproduje el comportamiento anterior en el siguiente sistema (usando Citrix):
Windows Server 2003 Enterprise Edition
Versión 5.2 (Build 3790.srv03_sp2_rtm.070216-1710: Service Pack 2)
Microsoft Word 2000 (9.0.6926 SP-3)
Utilicé Delphi 7 (compilación 8.1) para crear la aplicación.
Al alojar aplicaciones de Office a través de ActiveX, encontrará que algunas versiones de algunas aplicaciones de Office son ridículamente delicadas acerca de estar informado de los cambios de activación de la ventana y esto puede afectar especialmente sus menús contextuales.
Básicamente, si no les dice cuándo pierden o ganan el enfoque y también cuando su ventana de nivel superior gana o pierde el enfoque (incluso si el control de su hijo en la ventana no se está enfocando), entonces pueden volverse locos.
Es algo con lo que luché durante mucho tiempo y especialmente frustrante cuando tienes que decirle a las aplicaciones que saben que están en una mejor posición que tú (como cuando pierden o ganan el foco directamente ... o cuando cree un menú emergente que quite el enfoque de ellos y tenga que manejarse de manera diferente a otras aplicaciones / ventanas que quitan el enfoque, lo que le queda a divino ... Ugh.
De todos modos, las aplicaciones de Office deben exponer una interfaz IOleInPlaceActiveObject y usted debe asegurarse de que llama a su método OnFrameWindowActivate para informarle sobre la activación / desactivación.
Desde la memoria, y un vistazo rápido a mi propio código para hospedar Office, esa es una de las cosas más importantes. También es una cosa fácil de pasar por alto, pensando "No, no importa mucho ... ¿Por qué a alguien le importa mucho si la ventana está activa o no?" Podría pensar que solo podría llevar a algunos problemas estéticos menores (como aparecer activo cuando no lo está), pero puede llevar a que todo se bloquee o se bloquee. Confía en mí, Office se preocupa demasiado por esas cosas! Me da la impresión de que debajo de las coberturas de Office todavía hay un diseño muy antiguo de un solo hilo desde los días de la cooperativa multitarea que se agolpa y se puede confundir mucho cuando dos de sus ventanas parecen estar activas al mismo tiempo.
Lo siento, no puedo dar más consejos que solo apuntar en esa dirección ... Escribir hosts ActiveX es un arte negro (toda la documentación está orientada a ser alojada, no a ser el host :() y la única forma en que obtuve mi propio código para el trabajo fue a través de meses de prueba y error y un montón de debug-out. Es una pesadilla, desafortunadamente.
Un último consejo: no tenga miedo de codificar los códigos para aplicaciones particulares. Esto es lo que hace el propio IE, con la configuración del registro para controlar qué kludges se aplican a qué (y sospecho que hay algunos más codificados en el código). ActiveX es un desastre tan mal definido que varios controles tienen sus propias peculiaridades y errores y es imposible escribir un host genérico y limpio que funcione con todos ellos. (Un cambio que corrige uno romperá otro). También encontrará cosas que solo funcionan si prueba las interfaces en el mismo orden que IE, solo porque solo se probaron con IE; hacen las cosas de manera ligeramente diferente y se deshacen. :(
Me pregunto si podría detectar un evento de tipo Lost Focus desde el formulario que contiene el contenedor OLE, momento en el que podría destruir el documento en el contenedor OLE pero mantenerlo en la memoria. Luego, en cualquier evento de tipo Got Focus para el formulario, puede verificar si tiene ese documento; Si es así, vuelva a cargarlo en el contenedor OLE.
¿Eso funcionaría para ti?
Tal vez puedas usar un componente para invocar la aplicación. Nunca tuve problemas para crear un componente personalizado para invocar word a través de interfaces y luego registrar comandos especiales en el menú. En un contenedor, ¿no puede diseñar un menú especial en el formulario? Hay algunos Evenets de WordSink que ayudarán a guardar y cerrar que podrían usarse junto con los objetos word com.