Probando la función RealGetWindowClass

[Al González]

Un favor. Les estaré agradecido si pudieran realizar esta sencilla prueba en Delphi de la función de la API de Windows RealGetWindowClass y decirme qué resultado les arroja en pantalla:

Function BaseClassName (Const Window :THandle) :String;
Var
Name :Array [0..255] Of Char;
Begin
SetString (Result, Name,
RealGetWindowClass (Window, Name, Length (Name)));
End;

procedure TForm1.Button1Click(Sender: TObject);
begin
ShowMessage (BaseClassName (Button1.Handle));
end;

En mi caso y con Windows XP, la cadena que devuelve BaseClassName es 'Button'. Me interesa conocer si esto será así en todas las versiones de Windows, o si en algunos casos Windows pudiera devolver la cadena totalmente en mayúsculas.

La duda me surge a raíz de que toda la documentación oficial sobre las clases predefinidas de Windows, refieren a éstas con letras mayúsculas (BUTTON, EDIT, COMBOBOX, etcétera). Quiero estar seguro de que si RealGetWindowClass devuelve "Button", entonces siempre será "Button" y no a veces "BUTTON".

Muchas gracias, saludos. :)

[ecfisa]

Hola Al.

Windows Vista : Button
Windows 7 : Button


Saludos. :)

[egostar]

Hola Alberto

[Window Title]
Project1
[Content]
TButton
[OK]

Windows 7, Delphi XE2 y XE3

Saludos

[nlsgarcia]

[Al González],

En Windows XP Professional SP3 x32 la función BaseClassName retorna : Button

En Windows 7 Professional SP1 x32 la función BaseClassName retorna : Button

En Windows 7 Professional x64 la función BaseClassName retorna : Button

Espero sea útil :)

Nelson.

[Al González]

Gracias ecfisa, Eliseo y Nelson. :)

Eliseo: Me llamó la atención tu resultado. Acabo de hacer la prueba en XE2 y Delphi 2007, y en efecto, me da 'TButton' cuando en Delphi 7 arroja 'Button'. :confused:

Esto podría significar que algo cambió en la VCL respecto a la forma de hacer superclasificación (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633569%28v=vs.85%29.aspx#winproc_superclassing). Con esto le sale otro tentáculo al problema que intento solucionar, ya que pensé que sólo habría de preocuparme el asunto de las mayúsculas y minúsculas, y casi daba por hecho que RealGetWindowClass serviría para obtener el nombre de la clase Windows sobre la que se basan algunos controles.

Trato de encontrar el mecanismo por el cual, teniendo un identificador de ventana Windows (HWND) que no necesariamente sea de un objeto Delphi, pueda determinar si ese identificador es de un botón de presión normal, un cuadro de verificación (check box), un botón de radio (radio button), u otro tipo de objeto. Una dificultad estriba en que los tres primeros tipos de controles comparten en Windows la misma clase: "Button", pero se resolvería apoyándome en la función GetWindowLong con el parámetro gwl_Style para saber cuál de los tres tipos es. No podría usar solamente ésta última, porque las constantes de estilo comparten valor entre diferentes tipos de objetos Windows.

Lo primero es determinar si un Handle dado es "Button" o no es "Button". GetClassName no sirve para eso con objetos Delphi y de otros lenguajes, ya que devuelve el nombre que una clase de componente registra en Windows (TButton, TCheckBox, TRadioButton). Como es de suponerse, estos nombres no son de fiar para determinar lo que se busca (podría haber un componente TColorCheckBox y no por que diga "CheckBox" significa que sea un cuadro de verificación). En cambio, y al menos en Delphi 7, RealGetWindowClass devuelve el nombre de la clase base, que por lo general es nativa de Windows y eso da cierta certeza.

Pero ahora veo que Delphi 2007 o alguna versión anterior cambió esta regla y no será posible usar RealGetWindowClass...¿no será un "bug"? Lo sé, debí poner un título más descriptivo y empezar por detallar el objetivo, pero como creí que sólo iba a ser una cuestión de mayúsculas y minúsculas... :o

Vamos a descansar, habrá de ocurrírsenos algo... :)

[Al González]

Encontré que la función de Windows GetClassInfo podría ser la culpable, o más bien señalar al culpable. GetClassInfo trabaja de manera distinta si se activa la opción de proyecto Enable runtime themes. qP:-)

Cuando se compila con esa opción, la cadena que devuelve RealGetWindowClass es 'TButton' y cuando no, la cadena devuelta es 'Button' (la que espero obtener). Esto ocurre porque momentos antes se llama a GetClassInfo para llenar una estructura WNDCLASS (lo cual es normal), pero el campo lpfnWndProc de esta estructura queda con un valor diferente al esperado cuando se utilizan "temas". Los invito a hacer nuevamente la prueba de antes con y sin temas. :)

Toca indagar más sobre esta característica y ver qué tanto obstaculiza obtener la clase base de un HWND...

Saludos y gracias nuevamente.

[roman]

Esto ocurre porque momentos antes se llama a GetClassInfo para llenar una estructura WNDCLASS

¿Momentos antes de qué?

// Saludos

[Al González]

¿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.

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;
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 (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633569%28v=vs.85%29.aspx) 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 :D

[Al González]

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 :D

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 (http://blogs.msdn.com/b/oldnewthing/archive/2008/01/29/7294949.aspx)

What's up with RealGetWindowClass()? » Forum Post by Ian Hanschen (http://forums.joeuser.com/3258/page/1/)

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.