FiveTech Support Forums

Bueno, tal como habia anticipado, es una tontería. Los amigos de moc.eviflanac me dieron la solución:
"Hola amigos

La solucion es devolver un 0 en el metodo display.

Duerman tranquilos

menos mal. Mi agradecimiento y reconocimiento. Juntos vamos mejor.

Un saludo,

Carlos

Bueno, hemos localizado un ordenador en el que falla.

La prueba anterior no llega a sonar, luego los mensajes WM_PAINT no llegan recursivamente.

Si se desactiva el doble buffer, entonces casi deja de fallar. Lo que esté fallando se incrementa al usar el doble buffer.

Carlos,

En el problema del brush en la ventana principal, devolver un cero no lo soluciona

En realidad no me preocupa, he vivido con eso mas de cinco años. Si algun usuario quejoso me reclama le digo que es problema de su equipo (si le gusta que lo use y si no que busque otra opción).

Pero sería bueno solucionarlo.

Alfredo,

Nos gustaría solucionarlo y ojalá lo consigamos. De todas formas parece que está muy relacionado con la versión de Windows y con la velocidad del ordenador.

En Vista 32 con un Core Duo no hay forma de hacerlo fallar. Y es el mismo EXE que falla en otro ordenador con XP y más lento.

Comparando Vista con XP, resulta que en Vista no nos envian mensajes WM_PAINT cuando movemos otra ventana por encima de la nuestra. Es algo que han arreglado en Vista: detectan si no ha cambiado la imagen de la ventana y se ahorran de enviar y procesar mensajes WM_PAINT.

En cambio en XP, si nos envian mensajes WM_PAINT cuando movemos otra ventana por encima.

Posiblemente estamos tratando dos problemas distintos:

Hemos modificado FWH para que siempre devuelva cero al tratar el mensaje WM_PAINT. Eso debería arreglar el problema de pintado de los controles pero no soluciona el problema del pintado del brush de la ventana principal

ANTONIO

Hemos modificado FWH para que siempre devuelva cero al tratar el mensaje WM_PAINT. Eso debería arreglar el problema de pintado de los controles

a q te refieres con lo anterior, lo del agregar un CERO a EndPaint como indicaste soluciono el problema,, aunque se genera un pequeño retardo en el pintado,, es como si ese cero agregado relentizara el pintado,, pero no falla .....

a parte de ese CERO hay algun cambio mas ???? como dijiste hemos modificado FWH.... o solo te referias el agregar el cero como indicaste--

GRACIAS

Solo hay que añadir ese cero al final en EndPaint()

Antonio fijate que probe haciendo el cambio de ponerle el cero (el de la sugerencia fue carlos, no yo, jeje) en el endpaint(), y no me va, sigue pintando mal, y aparte me bloquea el sistema completo... asi tengo mi codigo

DEFINE WINDOW oWnd TITLE oVarSys:NomSys MDI MENU MiMenu() ICON oIcon

.......
ACTIVATE WINDOW oWnd MAXIMIZED ;
ON PAINT Showlogo(oWnd, nColor)

Function ShowLogo(oWnd, nColor)
Local oBmp, cFile, _nFil, _nCol, aCoors := GetCoors( GetDesktopWindow() ) // la pos 3 y 4 dan la resolucion de pantalla

cFile := "Fondo1024.jpg"

_nFil := GetWndRect(GetDesktopWindow())[3]
_nCol := GetWndRect(GetDesktopWindow())[4]

If File(cFile)
    @ 0,0 Image oBmp OF oWnd:oWndClient ;
                     NOBORDER PIXEL SIZE _nCol,_nFil
    oBmp:LoadImage(,cFile)
    oBmp:refresh()
 Else
    FillWnd( oWnd:oWndClient, nColor )
 Endif

return nil

Que estoy haciendo mal?
Gracias
Paco

Paco,

Prueba a no llamar a ShowLogo()

Paco, tu código crea un control cada vez que se pinta la ventana!!!
@ 0,0 Image oBmp ...
Eso jamas se debe hacer

Probare Antonio, voy a cambiar mi codigo para poner la imagen en el area de cliente, aver como adapto eso,
Gracias
Paco