Multiples timers vs un timer central

[Victor Espina]

Tengo un componente basado en Container que muestra una cierta informaion, y que cotinene un timer que permite que la informacion mostrada se actualize cada cierto tiempo.

Tengo un form que puede contener decenas de estos componentes, cada uno con su propio timer.

Pregunto. en base a su experiencia, hay algun problema relacionado con tener 10 o mas timers funcionando simultaneamente (a pesar de que se disparan en tiempos distintos) ?  seria preferible tener un solo timer que se disparara a una frecuencia menor y que fuera actualizando manualmente los componentes a los que les "toque" actualizarse?

Saludos

Victor Espina

[Walter R. Ojeda Valiente]

Hola Víctor

Nunca use 10 timers al mismo tiempo, lo máximo fueron 4 y no tuve ningún problema con ellos.

Saludos.

Walter.

---

Date: Wed, 2 May 2012 12:48:44 -0700
From: vesp...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Multiples timers vs un timer central

[Luis Maria Guayan]

Victor, yo utilizo pantallas con Timers, pero nunca abusando de la cantidad, ni de un Interval muy pequeño. Lo que siempre hago en el evento Timer de cada control Timer es deshabilitarlo al inicio y habilitarlo al final. Ej:

::Timer.Timer
This.Enabled = .F.

** Aquí el código del Timer

This.Enabled = .T.

Imagino que la actualizaciones que indicas serán cada 5 a 30 segundos (5000 a 30000 milisegundos) con lo que imagino no tendrás inconvenientes.

La idea de un solo Timer, en el cual recorras los "n" contenedores y vayas actualizando de uno por ciclo me parece muy buena.

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Victor Espina]

Si, la idea es que cada componente tiene su propio intervalo de refresco que puede ir desde unos 10 o 15seg hasta 5min. Actualmente, como dije, cada uno tiene su propio timer pero por alguna razon el tener 20 o mas timers activos no me parece una buena idea.

Lo que queria era confirmar si alguien habia manejado esa cantidad de timers y si tuvo algun problema relacionado con ello, antes de lanzarme a crear una clase que podria resultar innecesaria, aunque definitivamente interesante.

Saludos

Victor Espina

[Sharp User]

Suena interesante el concepto de una clase que emplee cualquier cantidad de timers (no solo 10) y creo que tanto su uso y aplicación no debería generar ningún problema al trabajar de manera simultánea.

Pero coincido que la mejor idea es usar un solo Timer, en el cual recorras los "n" contenedores y vayas actualizando de uno por ciclo. 

En procesos electrónicos creo que es lo óptimo.

[Mario López]

@Victor:

y si en vez de 20 timers usás uno solo y en el mismo un objeto
Collection que apunte
a los controles a actualizar? (patrón Observer :)))
De esa forma no tendrías problemas de ordenamiento entre sí si alguno
de los controles
depende del resultado de un control anterior.

Yo utilizo algo como lo anterior para ejecutar actualizaciones de
interface (la idea la
tomé del dabo.ui.callAfter de Dabo): uso un único control timer de
actualización, voy
agregando los eventos actualización al final de la cola de ejecución y
los remuevo
después de ejecutados (previo deshabilitar el timer en el medio para
"serializar" el
proceso). Esto me evita muchos dolores de cabeza con respecto a
garantizarme que
los datos ya fueron actualizados en las tablas, ya que trabajando con
BINDEVENT
hay determinadas ocasiones en la que el .Value del control todavía no
se refleja en
el campo base.

Saludos,
Mario

---

[Victor Espina]

Mario, justo eso es lo que estoy pensando: una clase Timer centralizada que funcione como un Observer con muchos subscritores pero un solo proveedor: el mismo.

Lo que pasa es que por mas bonito que se vea, si no hay ningun problema con tener 20 timers (o mas) activos al mismo tiempo, entonces es una perdida de tiempo porque estaria creando una solucion para un problema que no existe.

Saludos

Victor Espina

[Mario López]

@Victor:

bueno, en mi caso el problema sí existía porque el orden de ejecución
era importante,
ya fuera porque el estado de algunos controles actualizables dependía
del estado de
otros o porque simplemente usaba el timer como una cola de ejecución
de comandos.
Pero, ya sabés como dicen, YMMV :)

Saludos,
Mario

---

[Victor Espina]

Es cierto.  Cuestion aparte, el patron Observer es quizas uno de los mas bonitos de los que estudie en su tiempo, y el 2do que implemente (el primero fue el patrion Factory, el cual siempre me ha parecido simplemente genial).

Saludos

Victor