Probando la función RealGetWindowClass

[[Al González]]

Empezado por roman

¿Momentos antes de qué?

Momentos antes de la prueba del primer mensaje (admito que la frase fue ambigua).

Esto se explica porque para hacer superclasificación (el enlace de mi segundo mensaje), se recurre en primer lugar a la función GetClassInfo para obtener información de la clase ya registrada sobre la cual se quiere crear una "derivada". No hablo de clases de objetos propiamente, sino de lo que Microsoft llama window class en el ámbito de su sistema operativo

En Delphi, esa llamada a GetClassInfo ocurre desde el método TWinControl.CreateSubClass al crearse objetos como TEdit, TButton, TCheckBox, etcétera.

Código Delphi [-]
procedure TCustomCheckBox.CreateParams(var Params: TCreateParams);
const
  Alignments: array[Boolean, TLeftRight] of DWORD =
    ((BS_LEFTTEXT, 0), (0, BS_LEFTTEXT));
begin
  inherited CreateParams(Params);
  CreateSubClass(Params, 'BUTTON');
  with Params do
  begin
    Style := Style or BS_3STATE or
      Alignments[UseRightToLeftAlignment, FAlignment];
    WindowClass.style := WindowClass.style and not (CS_HREDRAW or CS_VREDRAW);
  end;
end;

Código Delphi [-]
procedure TButton.CreateParams(var Params: TCreateParams);
const
  ButtonStyles: array[Boolean] of DWORD = (BS_PUSHBUTTON, BS_DEFPUSHBUTTON);
begin
  inherited CreateParams(Params);
  CreateSubClass(Params, 'BUTTON');
  Params.Style := Params.Style or ButtonStyles[FDefault];
end;

Es decir, nuestro "botón de indias" Button1 es creado (al crearse el formulario, como es habitual), y luego lo presionamos con el fin de probar la función RealGetWindowClass. Pero el "daño" ya está hecho para entonces debido a lo que previamente regresó GetClassInfo, especialmente el campo lpfnWndProc de la estructura WNDCLASS. El valor de este campo queda relacionado de cierta forma con el objeto y eso es determinante, por lo que veo, para la cadena que regresa más tarde RealGetWindowClass.

El procedimiento al que apunta lpfnWndProc es uno cuando se usan "temas" y otro cuando no se usan. Tras llamar a GetClassInfo, lpfnWndProc es el Window Procedure de la clase que hemos consultado.

Perdón por tanto rollo. Cuando tenga todas las piezas veré si puedo ponerlo "en limpio".

[[Lepe]]

Al, como has hablado de "otros lenguajes de programación y tal..." ¿has pensado en suites de componentes?, Por ejemplo los jfControls definen un panel donde pintar, y a partir de ahí crean sus checkboxes (con imágenes definidas por el usuario), stringgrids, botones, grids, etc. todo desde la base de un panel.

Saludos y siento ser un agua fiestas

[[Al González]]

Empezado por Lepe

Al, como has hablado de "otros lenguajes de programación y tal..." ¿has pensado en suites de componentes?, Por ejemplo los jfControls definen un panel donde pintar, y a partir de ahí crean sus checkboxes [...] Saludos y siento ser un agua fiestas

Hola Lepe, no aguas ninguna fiesta.

Vaya que he considerado los componentes de terceros. Hasta ahora las pruebas que he realizado incluyen a los "cx" (Developer Express). Y desde el comienzo era de esperarse que la función RealGetWindowClass no fuese suficiente.

Hablando de esa función, en el camino encontré interesantes textos que no tienen desperdicio, como los siguientes:

The history of the Windows XP common controls

What's up with RealGetWindowClass()? » Forum Post by Ian Hanschen

De momento emplearé una solución "mixta", apoyada en:

1. La función de Windows RealGetWindowClass.- Para intentar obtener la clase base.
2. La función de Delphi FindControl.- Para obtener la instancia Delphi asociada a un HWND (cuando la haya) y comprobarla con el operador Is.

Y la que quizá sea la "solución diplomática" a todo esto:

3. Enviar a la ventana el mensaje estándar wm_GetDlgCode, que como respuesta "debe" regresar una combinación de las constantes:

DLGC_WANTARROWS = 1; { Control wants arrow keys }
DLGC_WANTTAB = 2; { Control wants tab keys }
DLGC_WANTALLKEYS = 4; { Control wants all keys }
DLGC_WANTMESSAGE = 4; { Pass message to control }
DLGC_HASSETSEL = 8; { Understands EM_SETSEL message }
DLGC_DEFPUSHBUTTON = $10; { Default pushbutton }
DLGC_UNDEFPUSHBUTTON = $20; { Non-default pushbutton }
DLGC_RADIOBUTTON = $40; { Radio button }
DLGC_WANTCHARS = $80; { Want WM_CHAR messages }
DLGC_STATIC = $100; { Static item: don't include }
DLGC_BUTTON = $2000; { Button item: can be checked }

Si el tercer punto se cumpliera siempre en los componentes de terceros (en mi opinión siempre debería responderse con la verdad al mensaje wm_GetDlgCode), los puntos 1 y 2 serían innecesarios. Pero sabiendo que algunos componentes de terceros no respetan del todo ese mensaje estándar, yo tampoco los respetaré demasiado; a lo mucho les ayudaré a "mostrar lo que son" empleando los otros dos mecanismos como refuerzo.

Parece que salvaremos el día.

Saludos.