¿A qué te refieres con ventana temporal Delphius? ¿Al intervalo del timer o al tiempo que podrían tardar los procesos dentro del timer?

Me refiero al intervalo del timer.
Una vez que el Timer se dispara cuenta con un minuto para realizar lo necesario, antes de que nuevamente se dispare.
Cuanto más simples sean los procesos mejor, ese tiempo que se dispone en el timer puede llegar a satisfacer con tranquilidad a los procesos.

Todo dependerá de que hará cada cosa y el tiempo que se necesite o demande para llevarlo a cabo. Lo importante es saber determinar un valor de intervalo que no sea ni largo ni corto. Tal vez llevar una especie de auditoria y monitoreo de cada proceso involucrado puede servirte para determinar el marco temporal adecuado.

Quizá hasta es viable establecer un modelo dinámico. Es decir, que el mismo sistema sea capaz de autoregular el intervalo del timer. Por darte una idea: se puede calcular un promedio o mediana (en algunos casos es más precisa la mediana) y en bases a nuevas mediciones recalcular el nuevo tiempo de espera. De este modo se puede llegar a conseguir mejores resultados ya que no se "desprecia" tanto uso del CPU en estar constantemente evaluando procesos que tal vez no tienen una gran prioridad o que no tienen una frecuencia tan elevada.
Un esquema basado en prioridades es útil en algunos casos.

En fin, es una alternativa o una mirada diferente a la que te han estado ofreciendo. A lo que quiero llegar es que deberías preguntarte: ¿Es realmente necesario un marco de un minuto? ¿Todas las actividades tienen la misma prioridad? ¿Cuáles son las probabilidades de que todos los procesos deban realizarse en un mismo instante?

Saludos,

Hola de nuevo,
Después de un tiempo meditando y viendo que podía ser mejor me decanté por la propuesta de Lepe y usé un registro por cada elemento para ver en qué momento debía de actualizarse.
No conforme del todo con el resultado obtenido me planteé el uso de threads, uno por cada elemento. Ahora mismo estoy en ello aunque tengo un par de dudas:
- Primero: No sé que pensáis qué es más conveniente si un timer y comprobar cada cierto tiempo si un elemento ha de actualizarse o, como estoy haciendo ahora, un thread por cada elemento y cuando le llegue su momento se actualizará.
- Segundo: Esta pregunta es por desconocimiento del funcionamiento de un thread. Un thread cuando finaliza su método execute hay que liberarlo? Cuando se libera deja la variable a la que lo tenía asignado con el valor nil? Teniendo en cuenta que cuando se está ejecutando el hilo y llega una actualización tengo que incrementar el periodo de finalizacion en intervalo, se puede usar la condición siguiente siendo fin una variable publica del hilo?:

Código Delphi [-]
if Elemento.hilo = nil then
    // Crear hilo
else
   Elemento.hilo.fin := Now+Intervalo;

Gracias!!!

Si lo haces por aprender threads, lo veo bien ;), pero desde luego la opción que elegiste es la más eficiente (no porque lo haya dicho yo, de hecho es una técnica bastante antigua).

Mira su propiedad FreeOnTerminate ;)
[quote=vejerf;324605]
Cuando se libera deja la variable a la que lo tenía asignado con el valor nil?
[/delphi]
Nunca. En delphi te asigna nil cuando usas FreeAndNil, pero no puede usarse con el thread, porque él es cuando decide liberarse.

Como norma general, no es bueno para tu salud mental usar variables con threads (es igual de lioso que una publica que no sabes quien la actualizó la última vez). De todas formas, la varible que se comparta en varias threads debe declararse así:

Código Delphi [-]
threadvar Una:string;

// en lugar del típico
var Una:string;

Para no usar variables públicas, lo mejor son eventos, y que un Thread informe cuando termine.

Saludos