Un TIMER miente!!!???!

[[Lepe]]

Un Timer de delphi no tiene fallos.

La verdad es que no veo la forma de contar, ya que ahí pillas un label, lo conviertes a datetime, despues le sumas una fracción, y por último le cambias el formato. ¿Donde está el timer? no lo veo por ningún sitio. Desde luego no es forma fiable de contar el tiempo, y mucho menos echarle la culpa al pobre Timer .

No sé como estas haciendo las cosas, pero yo usaría un timer simplemente poniendole el tiempo total que ha de esperar.

De todas formas, si necesitas más precisión, mira la ayuda de GetTickCount de la unidad Windows.

saludos

[dec]

Hola,

Empezado por Lepe

Un Timer de delphi no tiene fallos.

Bueno. Conste que yo no he querido decir eso, sino constatar el hecho de que existen "Timer's" con mayor resolución, por decirlo de algún modo. Me parece raro que sean cinco segundos de "desfase" los que se alcanzen, pero, he probado alguna vez alguno de los "Timer's más precisos" y, en los ejemplos que acompañan a dichos componentes suele haber una muestra, precisamente, de cómo estos son más precisos que los "TTimer" de Delphi. Lamento no recordar exactamente el componente en cuestión, pero, en el enlace de más arriba pueden encontrarse varios de ellos: probablemente incluyan ejemplos en que se muestre la diferencia entre ambos "TTimer"y "THighTimer", por llamar de algún modo al "TTimer especial".

[dec]

Hola de nuevo,

Acaso quepa añadir que, efectivamente, los "THighTimer's" son usados, me parece a mí, no en intervalos demasiado "largos"; es precisamente ahí donde muestran su mayor eficacia respecto a los "TTimer" que acompañan a Delphi. Quiere decirse que este puede medir un tiempo de "0.500" milisegundos, y acaso los otros rezen "0.230" segundos, o resultados por el estilo.

[[marceloalegre]]

Mi estimado lepe... se supone que como estoy hablando del timer, si hay un timer , lo que mostre de codigo es lo que esta adentro del timer.... ... no entiendo por que preguntas esooo....??
Si, quizas es porque dije que lo mando por socket... se puede interpretar otra cosa... o sea yo por socket mando la orden de que se active el timer con el codigo que he dejado expresado anteriormente, si se malentendio, mil disculpas!

En cuanto a lo que tu dices que el timer no tiene fallos... No me cierra bajo ningun concepto!!!
Imagina... tu pones un timer a hacer "algo" a 1000 ms...
perfecto....
emmm imagina que los recursos del cpu estan al 80 % o sea la pc esta a full....

entonces... no imaginas que el timer se ir un poco de tiempo imaginemos...
1010 ms.... o sea.,, si muestro algo en pantalla considero que siempre poco a poco se va a ir adelantando...

Lo digo comprobado empiricamente.. agarramos las pc y pusimos a tirar datos por pantalla con algunos for's paralelos para sacar recursos al procesador... y el adelanto fue detectado perfectamente... asi que si... el timer no es perfecto...
Ahora si , con GetTickCount haciendo lo debido, podria solucionar el problema....


Saludos!.

[Casimiro Noteví]

Por mi experiencia, y por lo que he leído , sé que el timer de delphi no es muy exacto. Si requieres más precisión o necesitas de varios timer te aconsejo el que trae las RX, que tiene la particularidad de ser un TrxTimerList, así con un único "componente" en tu programa puedes gestionar multitud de timers.

[[Lepe]]

Empezado por Casimiro Notevi

Por mi experiencia, y por lo que he leído , sé que el timer de delphi no es muy exacto. Si requieres más precisión o necesitas de varios timer te aconsejo el que trae las RX, que tiene la particularidad de ser un TrxTimerList, así con un único "componente" en tu programa puedes gestionar multitud de timers.

El Timer tiene como límite, los milisegundos, si quieres diezmilesimas, entonces si necesitas mayor precisión y tienes que usar otra técnica.

Este es el punto que quería aclarar.

saludos

[[Lepe]]

Me quedé pensando y al final, ni siquiera GetTickcount es fiable.

Mira este truco de Ian Marteens.

[[Lepe]]

Empezado por kanvictor

Mi estimado lepe... se supone que como estoy hablando del timer, si hay un timer , lo que mostre de codigo es lo que esta adentro del timer.... ... no entiendo por que preguntas esooo....??

No dijiste que ese código está dentro del evento OnTimer.

Creía que estabas midiendo el tiempo con esa expresión, y desde luego, realizar conversiones de texto a número y sumarle fracciones de tiempo no es la forma de medir el tiempo. La forma correcta sería con GetTickCount, si quieres toda la precisión.

Dices que el resultado de esa expresión es la que se usa para enviarla por sockets. Creía que esa expresión era la que realmente medía el tiempo !!

Yo he realizado pruebas de ese estilo con timers, y no he tenido retardo, en realidad los retardos se producían en mi código, y creo que tambien es tu caso (intuyo).

Dentro del timer, ejecutas ese código (ya consume algo de tiempo, mínimo, porque son 3 o 4 conversiones), despues lo envias por sockets, (tambien se consume un tiempo más considerable), el programa Cliente Recibe el tiempo que ha de activar su timer y lo pone en marcha, Justo en este punto es cuando debes empezar a contar el tiempo.

Si usas un reloj de pulsera, tambien hay retardos en pulsar el botón o parar el crono, por tanto no es fiable.

No es lógico medir el tiempo desde antes de lanzarlo por sockets.

Quizás lo esté entendiendo de otra forma .

En cuanto a que el sistema esté al 80 % y se pase por alto, o se retrase..., solo puedes darle prioridad a tu proceso en windows, para que windows lo trate con más "atención" que al resto. Pero en este caso, no se trata de retardos del timer, sino retardos de Windows en procesar el mensaje desde el cronómetro interno del sistema (hardware) hasta que llega a tu aplicación.

Lo ideal, como estas viendo es unir la prioridad de proceso con GetTickCount.

Espero que ahora me haya expresado mejor.

saludos