2009-12-01 4 views
5

Para evitar que mi aplicación cambie el contenido de la ventana mientras el usuario mueve su ventana, capturo los mensajes WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE y pause la aplicación entre los mensajes. Sin embargo, a veces sucede que recibo WM_ENTERSIZEMOVE pero no WM_EXITSIZEMOVE en absoluto. Una repro es:WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE - al usar el menú, no siempre emparejado

  • abrir el menú de la ventana
  • clic en Tamaño
  • no cambiar el tamaño de la ventana, en lugar haga clic en la ventana de

la ventana Aviso nunca recibió ninguna WM_EXITSIZEMOVE.

Al comprobar cómo funciona esto, también he comprobado la muestra de Microsoft DirectX y he notado el mismo problema. Una vez que siga los pasos de repro anteriores, la aplicación de muestra se ve congelada (lo he intentado con BasicHLSL sample from March 2009 SDK).

¿Cómo se espera que responda la aplicación? ¿Hay alguna otra condición que deba terminar con el "" ciclo modal o de desplazamiento "?

Respuesta

0

Como una solución temporal, ahora apago la aplicación cada vez que recibo el mensaje WM_ACTIVATE. Esto parece haber solucionado un problema en este caso particular (puedes recuperar la aplicación activándola de nuevo) y no parece romper nada.

Sin embargo, esa solución me huele. Preferiría entender cómo debería funcionar, en lugar de basarme únicamente en una prueba limitada.

-1

Debe recibir el mensaje WM_SIZE cada vez que finaliza una operación de dimensionamiento. Y al dimensionar, obtendrá mensajes WM_SIZING.

¿Tal vez podría utilizarlos también para reanudar su aplicación?

+0

El problema es con los pasos de reproceso dado que no hay operación de dimensionamiento en absoluto. Se ingresa el ciclo modal de dimensionamiento, pero el tamaño nunca se inicia realmente. – Suma

4

Sé que esto es bastante tarde, pero aún podría ayudarlo, y es probable que ayude a otros que lo encuentren en una búsqueda, como yo lo hice.

Parece que en la situación que mencionó, el mensaje WM_CAPTURECHANGED se envía cuando se cancela el cambio de tamaño. Después de extensas pruebas, parece que esto siempre se envía justo antes de que WM_EXITSIZEMOVE esté (¡o debería ser!), Y en ninguna otra etapa entre WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE.

El mensaje WM_CAPTURECHANGED se envía también en otros momentos, por lo que solo debería reaccionar si se ha enviado un mensaje WM_ENTERSIZEMOVE, pero el siguiente WM_EXITSIZEMOVE no lo ha hecho.

Cuestiones relacionadas