windows - lpclassname - window styles winapi

Win32: CreateDialog en lugar de múltiples llamadas a CreateWindow, ¿alguna desventaja?

Question

Actualmente estoy trabajando en un programa Win32 que requiere una ventana principal que contiene muchos controles de ventanas secundarias: botones, listas de vista, etc. Creo que la forma estándar de crear una ventana de este tipo es llamar primero a CreateWindow para la ventana principal, luego nuevamente para cada uno de los controles.

Como una opción más fácil, estoy considerando diseñar la ventana principal usando el diseñador del cuadro de diálogo del editor de recursos, luego usar CreateDialog para construir la ventana principal de una vez.

Al usar una declaración CLASS en la plantilla del cuadro de diálogo, debería ser capaz de hacer que la ventana principal use una clase de ventana personalizada (y por lo tanto un procedimiento de ventana personalizado) y así evitar que la ventana tenga un comportamiento parecido al de un diálogo. Un ejemplo de esta técnica se puede encontrar en "Windows Programming" de Charles Petzold: el programa HEXCALC en el capítulo 11 .

¿Hay algún inconveniente para crear mi ventana principal de esta manera? Si es así, ¿Que son? Si no, ¿por qué este enfoque rara vez se usa?

Answer 1

Podrá tener el control total sobre su ventana, incluso si fue creado con CreateDialog .

Normalmente, cuando creas tu propia ventana (de tu clase), el procedimiento de ventana utilizado es el que registraste con la clase. Las ventanas OTOH creadas a través de CreateDialog tendrán el procedimiento de ventana estándar de diálogo ( DefDlgProc ), que invocará principalmente el "controlador de diálogo" suministrado.

Si desea tener un control total de todos los mensajes, puede reemplazar el proceso de ventana de la ventana recién creada inmediatamente después de su creación. Simplemente llame a SetWindowLongPtr con el parámetro GWLP_WNDPROC . Aún así, puede hacer el procesamiento automático de algunos elementos específicos del diálogo llamando a IsDialogMessage dentro de su procedimiento.

Answer 2

No obtiene el control del bucle de mensajes de la ventana principal; el administrador de diálogos lo maneja por usted. Por otro lado, el administrador de diálogos maneja aceleradores de teclado, ordenamiento de tabuladores y una cantidad de otros efectos.

Se sorprendería de lo que puede hacer con un cuadro de diálogo estándar; el control de volumen de Windows se implementa con aproximadamente cuatro cuadros de diálogo diferentes; tiene un cuadro de diálogo de marco que a su vez aloja una ventana de bandeja que a su vez contiene cuadros de diálogo de control de volumen , uno para cada volumen de aplicación.

Answer 3

No hay inconveniente alguno.

¿Por qué rara vez se usa? Porque:

• Normalmente, las personas usan DialogBox , ya que es más fácil para casos más simples.

• Para casos más complejos, las personas usan cosas como MFC o ATL (o alguna biblioteca externa como GTk o Qt), y no se molestan con los gráficos nativos de Win32.

Answer 4

La única desventaja de CreateDialog que conozco (en comparación con CreateWindow repetido, sin hablar de algún framework de peso pesado, solo Win32 vs Win32) es que los recursos de diálogo colocan ventanas secundarias usando unidades de diálogo. Por lo tanto, el diseño no solo depende del DPI, sino también de la configuración del tema del usuario (elección y tamaño de la fuente).

Si alguno de sus controles necesita tener tamaños fijos en términos de píxeles, no estará satisfecho con el posicionamiento proporcionado por el diálogo y deberá pasar y mover todas las ventanas secundarias después del hecho.

Entonces sí, puede usar CreateDialog como un acceso directo para crear un grupo de ventanas con clases y estilos específicos. Pero no, no puede hacer su diseño en el editor de diálogo.

OTOH, podría almacenar la conversión de DLU <-> píxel utilizada en su máquina de diseño, y luego aprender lo suficiente sobre el análisis del formato interno del recurso DIALOG para extraer la información de posicionamiento, luego convertir a píxeles y corregir el posicionamiento de manera más automatizada.

Answer 5

No hay inconvenientes con el SDK de Windows, las bibliotecas internas como MFC usan el SDK de Windows.

La gente tiende a usar bibliotecas como MFC sobre Windows SDK, ya que las librerías tienen las cosas preparadas. Sin embargo, las llamadas al SDK de Windows son más rápidas que las llamadas a la biblioteca, por lo que en algunas situaciones los desarrolladores llaman al SDK de Windows directamente.

CButton btnOk ;
btnOK.Create(_T("Press Me"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(100,100,300,300), pParentWnd, 1);

es similar al siguiente código,

HWND hWnd = CreateWindow("BUTTON","Press Me",WS_CHILD|WS_POPUP|BS_DEFPUSHBUTTON,100,100,300,300,NULL,NULL,GetModuleHandle(NULL),NULL);
ShowWindow(hWnd,SW_SHOW);