Carlos,
Si tu teoria es correcta entonces podrÃamos usar una variable estática (lPainting) que en caso de ser verdadera servirÃa para no hacer más pintados mientras que no se termine el anterior.
En una primera prueba habrÃa que comprobar si recibimos un WM_PAINT estando procesando ya un WM_PAINT anteriormente
De la misma forma, podriamos comprobar si se recibe un WM_ERASEBKGND estando procesando un WM_ERASEBKGND anterior
Antonio Linares wrote:
Si tu teoria es correcta entonces podrÃamos usar una variable estática (lPainting) que en caso de ser verdadera servirÃa para no hacer más pintados mientras que no se termine el anterior.
La clase TWindow es una clase propia de FWH por lo que entra dentro del grupo de clases que pueden tener ese problema.
La cuestión es encontrar la causa y la solución
Alfredo efectivamente sucede con cualquier aplicacion externa a fwh, yo he probado en dialogs y windows con imagen de fondo (bmp y jpg) con degradado, con colores, y el comportamiento es exactamente el mismo, entiendo que es un bug muy desagradable, a ver si por ahi entre todos coperamos para salir adelante.
salu2
paco
He probado el asunto en 3 equipos con caracterÃsticas diferentes:
1) Pentium III de 500 Mhz con 448 MB en RAM y tarjeta de video AGP Matrox de 32 MB
2) AMD Athlon XP 2000+, 512 MB en RAM y tarjeta de Video AGP ATI Radeon 9200 de 128 MB
3) AMD Athlon 64 3500+, 512 MB en RAM con tarjeta de Video PCI Express ATI Radeon X300 de 256 MB
El comportamiento es el mismo en los equipos 1 y 2, hay gran consumo de recursos al mover sean diálogos propios o una aplicación externa encima de nuestra ventana FW. Si movemos toda nuestra aplicación sobre el escritorio llega a consumir hasta el 100% de los recursos.
Pero en el equipo 3 no ocurre nada de lo anterior, si movemos cualquier diálogo no llega a consumir más de 2%. Si movemos la ventana entera no llega a consumir el 20%, ¡aquà todo va como la seda!. Será que el puerto PCI Expres tiene algo que ver, al ser más eficiente?
Finalmente probé en modo seguro (a prueba de fallos) donde sólo se carga los controladores básicos de video (VGA), y.... Horror!!!!. En los tres equipos el resultado es peor, un desastre.
La constante en todas las pruebas es que las aplicaciones FW consumen por lo menos un 30% más de recursos que otras, produciéndose por tanto una lentitud en el refresco de los controles mucho más apreciable que en otras aplicaciones. Entonces creo que se debe investigar en qué parte del corazón de FW hace que el requerimiento de recursos sea grande.
Una solución (temporal) para evitar ese efecto horrible es desactivar la casilla "Mostrar el contenido de la ventana mientras de arrastra" en las propiedades del escritorio. Para evitar que se repinte constantemente el control.
Otra solución, que depende del cliente, serÃa la de recomendarle un equipo como el 3 de mi prueba o con mejores caracterÃsticas, que hoy por hoy ya son la constante.
Un saludo
Marcelo Jingo
Marcelo,
Vienen muy bien tus pruebas, te cuento que es muy significativo que otras aplicaciones se estan ejecutando en el ordenador, y más aún, que la ventana que se mueva por encima no sea la propia, por ejemplo la calculadora o la ventana de propiedades del equipo o cualquier otra. Eso hace que las ventanas de nuestra aplicaion se pinten de manera desincronizada y es cuando muestran los fallos.
No he notado fallos cuando la ventana superpuesta en una hija de la aplicacion, ni me ha dado problemas al moverla completamente.
Respecto de limitar el mercado de mis aplicaciones a Athlones 3200+ con tarjetas gráficas y cores duo... completamente en desacuerdo. No se me ocurrirÃa ni siquiera plantearle a un cliente que se compre una muleta porque estoy rengo.
Las soluciones tampoco estan ajustando la configuracion de windows para que no se dibujen las ventanas mientras se mueven, tal vez mejore la situación, pero es que me parece que hacer esos apaños por algo que no deberÃa existir ni siquiera deberÃa plantearse y es buscar parches y no soluciones.
Te aseguro que cuando lo encontremos el error va a ser una estupidez, nos va a dar vergüenza no haberlo visto antes, asi es que prefiero seguir dando con los cuernos contra la pared antes que bajar los brazos buscando rodeos.
Un saludo,
Carlos.
#include "FiveWin.ch"
function Main()
local oWnd
DEFINE WINDOW oWnd COLOR "W/G"
ACTIVATE WINDOW oWnd
return nilAntonio,
efectivamente tu código no falla. Lo estoy probando en el portatil (XP).
De esto que se deduce?
No he probado lo del bitmap. Luego de cenar me pongo. Voy a estar el el messenger como carlosantoniomora arroba yahoo punto es.
Carlos
Hola amigos,
me retracto a lo que comente en un mensaje anterior,
decia que solo es en algunas maquinas,
mentira,
es en cualquier tipo de pc, la mia es una tochiba,
y el error se reproduce en una windows con brush,
saludos..
Renuncio, me cambio a Visual Basic...
Jeje Alfredo, no es para tanto amigo,,
afortunadamente existen otros lenguajes,
alguna solucion tiene que existir,
no hay que desesperarnos,,
fivewin nos ha dado mucho,
saludos..
recordando hace tiempo tuve este problema de pintado, aqui lo que en ese momento publique,
http://fivetechsoft.com/forums/viewtopi ... highlight=
salu2
paco
