2008-10-04 13 views
18

Estoy tratando de incrustar una ventana de mi proceso en la ventana de un proceso externo usando la función SetParent y he encontrado algunos problemas que espero que alguien me pueda ayudar con. En primer lugar, aquí es un resumen de lo que estoy haciendo actualmente para incrustar mi ventana en la aplicación:Incrustar HWND en proceso externo usando SetParent

HWND myWindow; //Handle to my application window 
HWND externalWindow; //Handle to external application window 

SetParent(myWindow,externalWindow); 

//Remove WS_POPUP style and add WS_CHILD style 
DWORD style = GetWindowLong(myWindow,GWL_STYLE); 
style = style & ~(WS_POPUP); 
style = style | WS_CHILD; 
SetWindowLong(myWindow,GWL_STYLE,style); 

Este código funciona y mi ventana aparece en la otra aplicación, sino que introduce las siguientes cuestiones:

  • Cuando mi ventana ganancias foco de entrada, la ventana principal de la aplicación del proceso externo pierde el foco (es decir, la barra de título cambia de color)
  • comandos de acceso directo del teclado de la aplicación principal no funcionan mientras mi ventana tiene el foco

¿Alguien sabe una solución para esto? Me gustaría que mi ventana sea tratada como una ventana secundaria de la aplicación principal.

Respuesta

12

Bueno, finalmente encontré la respuesta a mi pregunta.

Para solucionar el problema con la aplicación principal que pierde el foco, necesita utilizar la función AttachThreadInput para conectar el subproceso de la ventana incrustada al subproceso principal de la aplicación.

Además, se puede utilizar la función TranslateAccelerator en respuesta a los mensajes WM_KEYDOWN para garantizar que se activen los mensajes del acelerador de la aplicación principal.

0

Encontré algo de información al Catch22.net usando el mensaje WM_NACTIVE.

Se encuentra en la sección Evitar la desactivación de la ventana. Espero que ayude.

4

No estoy seguro de si todavía está interesado en este tema después de casi tres años. Estoy trabajando en una aplicación similar. Mi solución es modificar el estilo de ventana antes de llamar a SetParent. Con esta solución, no tengo que llamar a AttachThreadInput.

Sin embargo, un problema importante del alojamiento de ventanas secundarias de un proceso externo es que si el proceso externo se bloquea al responder a un teclado de usuario o entrada de mouse, la aplicación principal también se congela. El bucle de mensajes en la aplicación principal aún se está ejecutando. Sin embargo, ya no recibe eventos de entrada del usuario. Por lo tanto, parece como si estuviera colgando. Creo que ese es el resultado directo de AttachThreadInput ya que los eventos de entrada de las dos amenazas ahora están sincronizados. Si uno de ellos está bloqueado, ambos están bloqueados.

0

Me encontré con el mismo problema, después de leer el documento de MSDN con cuidado, me pareció una solución fácil.

Debe eliminar WS_POPUP y añadir WS_CHILD ANTES se llama setParent

Se afirma en MSDN:

Por razones de compatibilidad, SetParent no modifica las WS_CHILD o ventana WS_POPUP estilos de la ventana cuyo padre es siendo cambiado Por lo tanto, si hWndNewParent es NULL, también debe borrar el bit WS_CHILD y establecer el estilo WS_POPUP después de llamar a SetParent.Por el contrario, si hWndNewParent no es NULL y la ventana era previamente un elemento secundario del escritorio, debe borrar el estilo WS_POPUP y establecer el estilo WS_CHILD antes de llamar a SetParent.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633541(v=vs.85).aspx

Cuestiones relacionadas