Cita:
Empezado por luiggixD
En teoria el hilo no debe detener a la aplicacion. Si dentro del hilo realizas operaciones que interactuan con el Form o con cualquier otra parte de tu aplicacion, lo mejor seria sincronizar(funcion_form), donde funcion_form es una funcion que defines dentro del hilo que encapsula todas las interacciones con el form, ahora puedes elaborar muchas mas funciones. El hilo no deberia detener al programa, y asi no empleas el Application->ProcessMessages();
me deje entender??
me parece raro que se congele tu programa empleando hilos XD! quizas en tu misma aplicacion estes haciendo algo que la retrase
|
..Si, tienes razón, el hilo no debe ni detiene la aplicación, la que lo detiene es la función WaitForSingleObject hasta que termina el hilo que se le pasa como parámetro (Handle).
El hilo debe interactuar con Synchronize con el form. Pero imagina que parte del código no puede seguir sin conocer un resultado. Y que ese resultado va a tardar en saberse. Entonces te puede interesar colocar en un hilo el código que sabes que va a tardar y por lo tanto semibloquear la aplicación unos segundos. ¿Y la espera...? Si la espera la haces con WaitForSingleObject, entonces es un desastre...
Con el sistema que propongo, la aplicación no espera nada, los eventos siguen ocurriendo, lo único que espera es el código que mantiene el bucle descrito.
Te preguntarás: Si al final usas ProcessMessages(), ¿Entonces porqué programar un hilo?. Pues para que las llamadas a ProcessMessages() no se interrumpan por la tarea que más tarde, por ejemplo una conexión a internet o llamada a procesos API que obligan a esperar...
Como
pulpin ha hecho la pregunta, he dado por hecho que estaba ante una situación como la que describo y por eso le propongo esto. Evidentemente es sólo para estos casos especiales de describo.
De todas formas
pulpin ha resuelto su problema.
Saludos.
