FiveTech Software tech support forums

Hola Antonio:

Sigo con problemas de actualización. Ahora con DIALOG TRANSPARENT y RADIOS.

Si tomas el ejemplo "TestRad.prg", en DEFIENE DIALOG... le das el atributo TRANSPARENT, quitas MsgInfo ("Select") del ON CHANGE del radio y te mueves por las distintas opciones del radio, verás que tiene un comportamiento errático en la pintada de los recuadros de la opción seleccionada.



Si le quito el atributo TRANSPARENT al Diálogo, funciona bien

Cómo puedo corregirlo, y estará esta corrección en el nuevo Build de FWH ?

Uso FWH 8.07, xHarbour 1.1.0 y Borland 5.51

Hasta la versión 8.05 de FWH no tenía este problema.

Gracias y saludos,

Carlos Gallego

Carlos,

Entiendo que lo que deseas es usar un brush para el fondo del diálogo, si ?

Hola Antonio,

En algunos casos utilizo brushs (con bmps o AlphaBitmaps), en otros colores, en otros la Clase TSTSay del maestro Manuel Mercado, en otros casos Groups con captions, etc., etc., etc. En general, la cláusula TRANSPARENT en los diálogos es casi que indispensable, salvo que sea un diálogo super-super sencillo.

El problema es que en todas mis aplicaciones y desarrollos especiales a clientes, por aquello de mejorar el look, incluyo intensivamente diálogos con TRANSPARENT.

Todo estuvo perfecto hasta la versión FWH 8.05. Ahora, que utilizo FWH 8.07, cada vez que tengo que tocar una aplicación por algún ajuste, cambio o adición (y esto es con frecuencia por solicitud de los clientes), al recompilarla salta el problema de la estética en los radios. Si quito la clausula TRANSPARENT los radios pintan bien, pero algunos de los otros controles dejan de tomar como fondo el color o el brush (según sea el caso), de los diálogos. Lo mismo pasa con TFolder y TPanel. Seguro que fue algún cambio que hiciste relacionado con TRANSPARENT en Diálogos que está ocasionando este comportamiento.

Por lo pronto, y como emergencia para los modificaciones que he tenido que hacerle a un cliente, he hecho lo siguiente en aquellos diálogos que tengo definidos desde recursos y en los que tengo algunos radios con su ID y algunos SAY que son simples textos y que no necesitan ID por lo que están identificados como -1.

A estos says si no tienen ID al pintar el diálogo sin TRANSPARENT les pinta mal el fondo, pero en cambio PINTA BIEN LOS RADIOS.
Si le pongo TRANSPARENT pinta BIEN LOS SAYS pero MAL LOS RADIOS.

Entonces, dejé los diálogos sin TRANPARENT y antes del ACTIVATE DIALOG puse:

Code: Select all  Expand view

For i:=1 TO Len(oDlg:aControls)
    if oDlg:aControls[i]:ClassName()=="TSAY"
       oDlg:aControls[i]:lTransparent:=.T.
    endif
next


Solución chapucera, pero me sacó del apuro. Pero, comprenderás, mortal si tengo que tomar todas las aplicaciones, y todos sus diálogos para hacer este modificación. Además se complica con otros controles.

Es posible revertir ese cambio. ? Cómo lo hago ?

Saludos y gracias,

Carlos Gallego

Carlos,

Has comparado el código de TRadio de la 8.05 y de la 8.07, por si hay alguna diferencia evidente ?

Antonio,

Tanto Radio.prg como Radmenu.prg son idénticas inclusive desde FWH 8.02

Estoy seguro que el problema se relaciona directamente con DIALOGOS y TRANSPARENCIAS.

Estamos haciendo un trabajo urgente para un cliente, y ahora tenemos el problema con TPAGES.

Se define un diálogo desde recursos, el cual incluye un TPAGE. De igual manera, desde recursos se definen las Páginas para TPage. En una de ellas se usan Radios.

El diálogo lleva de fondo un Brush con Bmp. Si defines el diálogo como TRANSPARENT no pone el brush de fondo en las páginas de TPage, además de que daña los radios.

Intenté con:

Code: Select all  Expand view

   for i:= 1 TO Len(oPages:aDialogs)
       oPages:aDialogs[i]:lTransparent := .T.
       oPages:aDialogs[i]:oBrush := oBrush
       oPages:aDialogs[i]:SetBrush(oBrush)
       oPages:aDialogs[i]:Refresh()
   next


Pero, con oPages:aDialogs[i]:lTransparent := .T. pone el brush en las páginas pero pinta mal los radios.

Si pones oPages:aDialogs[i]:lTransparent := .F. pinta bien los radios, pero NO PINTA EL BRUSH DE LAS PAGINAS.

Hemos probado de todo y no encontramos solución, salvo regresarnos a la versión FWH 8.02 . La locura. Se nos está atrasando completamente el trabajo.

Son las 7:45 p.m. y ya el cansancio y la frustración me tienen fundido.

Ahora son las 8:45 p.m. y encontré otra solución chapucera:

Code: Select all  Expand view

DEFINE DIALOG oDlg RESOURCE "DLG_PRINCIP" TITLE "La lucura de las actualizaciones";
         ICON oIcon1 BRUSH oBrush // TRANSPARENT

luego redefino TPage,

   REDEFINE PAGES oPages ID 180 OF oDlg DIALOGS "PAG_PAG1","PAG_PAG2"

le asigno el brush

oPages:oBrush:=oBrush

y antes del ACTIVATE DIALOG

For i:=1 TO Len(oDlg:aControls)
    if oDlg:aControls[i]:ClassName()=="TSAY"
       oDlg:aControls[i]:lTransparent:=.T.
    endif
next


Medio pinta el brush en las páginas del TPage (pues se lo asigné directamente ya que no hereda el del Diálogo). Aunque regular estéticamente, caminando rápido no se nota, pero en cambio, ahora a los Radios no les pinta, a todas las opciones, el cuadrito cuando pasas el mouse encima de las mismas, PERO, EN EL CAPTION DE LAS OPCIONES DEL RADIO NO PONE EL BRUSH.

Que frustrante. Por favor ayúdame. Dada la complejidad de la clase TDialogo, que a su vez hereda de TWindow, no me atrevo a meterle la mano (y ni tengo idea por dónde metersela) y ya estamos super atrasados, y como comprenderás, super desanimados.

Gracias y saludos,

Carlos Gallego

Un ejemplo:



1. Los Radios los deja sin Brush.
2. El brush asignado al Diálogo cubre toda su superficie por lo que no debería verse truncado. Si observas, verás que:

a.- a la izquierda del diálogo aperece cortado,
b.- dentro de la página de TPage repite el brush (lo cual es obvio, pues como no lo está heredando del diálogo, toca asignarlo directamente a la clase TPage y por eso se repite),
c.- rompe la continuidad del Brush original. Observa lado derecho y el bottom de la página de TPage

Saludos,

Carlos Gallego

Carlos,

Lamento que este asunto haya generado frustración y tanto esfuerzo

No es por buscar una excusa, pero la realidad es que Windows no provee transparencias en diálogos de forma estandard, es decir, soportadas directamente por el GUI de Windows, por lo que la forma de implementarlo es a base de buscarle las vueltas a Windows y encontrarle la forma de "colarse" en el pintado que él hace.

En tu caso además se complica el asunto pues estás usando un control TPages que a su vez gestiona diálogos no modales. Asi, la estructura que estas usando es:

1) diálogo
2) pages
3) dialogos del pages
4) radios situados sobre esos diálogos del pages

En esas circunstancias, como comentas, la transparencia no se está haciendo bien. Por supuesto que la estética es importante ("un coche ha de funcionar bien y si encima es bonito, aún mejor") pero siempre es preferible anteponer la funcionalidad a la estética.

Vamos a hacer algunas pruebas y ver si podemos ofrecerte una solución más adecuada. Gracias,

Hola Antonio:

En esas circunstancias, como comentas, la transparencia no se está haciendo bien. Por supuesto que la estética es importante ("un coche ha de funcionar bien y si encima es bonito, aún mejor") pero siempre es preferible anteponer la funcionalidad a la estética.

Ni modo, pero tienes razón.

Dejando al lado lo del brush, si creo importantísimo resolver lo de los radios, pues este problema persiste en un diálogo normal, sin brush. Si por alguna razón tienes que darle al diálogo el atributo de transparente, daña el pintado de los radios. El asunto es, que antes no pasaba esto. Por favor mira la imagen puesta al inicio de este hilo. Es el ejemplo "TESTRAD.PRG" con TRANSPARENT. Cada vez que pulsas sobre una de las opciones del radio, va quedando marcado. Antes no pasaba.

Con que solucionemos esto quedo tranquilo.

Gracias y saludos,

Carlos Gallego

Hola Antonio,

Alguna idea de cómo solucionar el pintado de los radios ? Verificaste el ejemplo \FWH\SAMPLES\TESTRAD.PRG con TRANSPARENT ?

Nadie más ha tenido este problema ?

Saludos,

Carlos Gallego

Carlos:

Mientras Antonio le busca la forma de solucionartelo,
quizas puedas usar la clase tsradio del Sr. Manuel Mercado.
Viene con la tsbutton y se llama tsradio.

Saludos

Ruben Fernandez.
(Creo que esta en utilidades, sino pidesela a MM)

Rubén, gracias por tu sugerencia.

Pero tampoco funciona. Si en el ejemplo TESTRAD.PRG que incluye el maestro Manuel, pones la cláusula TRANSPARENT en el diálogo que se define desde recursos, verás que aunque ya no pinta el cuadrado punteado sobre las opciones del radio, cuando seleccionas una por una, ahora no toma el brush definido de fondo. Antes funcionaba perfecto.

Definitivamente fue algo que cambio en TDialog o TWindow que está ocasionando conflicto con las tranparencias. Pero es que ANTES FUNCIONABA.

Antonio, por favor ayuda, no hemos podido recompilar ninguno de nuestros aplicativos usando FWH 8.07 por este problema. Por lo pronto hemos desmontado FWH 8.07 y reinstalado 8.02.

Ayudaaaaaaa.....

Gracias y saludos,

Carlos Gallego

Antonio,

Encontrado el problema. Está en TControl.

En el Method Colors, desactivaste la línea 429 , DrawPBack( ::hWnd, hDC ) y la reemplazaste por ParentImage( ::hWnd, hDC ).

Si se desactiva este cambio y se deja como estaba, con DrawPBack( ::hWnd, hDC ), el pintado de los radios VUELVE A FUNCIONAR BIEN.

- Porqué se hizo ese cambio
- Qué hace la función ParentImage( ::hWnd, hDC ) ( Aparte de dañar el pintado de los radios )
- Qué consecuencias trae el quitarla

Saludos,

Carlos Gallego

Carlos,

Estaba haciendo pruebas ahora mismo y justo te iba a comentar esto que me dices

DrawPBack() está basada en el API de "temas" de Windows y posiblemente se está encargando de quitar el recuadro punteado, pinta y lo vuelve a poner, para que quede bien.

ParentImage() es una función nuestra que copia el área de la zona padre que ocupa el control, al fondo de la imagen del control y no está controlando el recuadro punteado. De ahí el problema.

Puedes volver a cambiar la llamada a DrawPBack(). El usar ParentImage() es para copiar zonas dibujadas con brushes, y no solo limitarnos a los "temas" de Windows.

Si conseguimos solucionar el dibujado del recuadro punteado, entonces podriamos usar ParentImage(). Ese recuadro se pinta con una operación "xor", es decir, que al volver a llamarse borra la anterior. Se conmuta.

Carlos,

Estoy probando con DrawFocusRect() y tambien enviando WM_SETFOCUS ó WM_KILLFOCUS. La idea es quitar el recuadro punteado antes de llamar a ParentImage().

El enviarle esos mensajes provoca un bucle, ya que vuelven a generar un mensaje de pintado.

A ver si damos con la solución...

Carlos,

Andamos revisando el código fuente de DrawThemeParentBackground() de "Wine" para ver si nos la pista de lo que nos hace falta:

http://cvs.winehq.org/cvsweb/wine/dlls/ ... web-markup