Die Verarbeitung in einen Thread auslagern, der Threadklasse das
GUI Fensterhandle überreichen und dann mit Messages arbeiten dürfte der generischste und entkoppelteste Weg sein, den du erreichen kannst. Dabei steht dir dann u.a. auch frei, ob und welche Messages du überhaupt nachher anzeigen lassen willst, und in welcher Form (Text, Gauge, Balken etc.).
Noch weiter gedacht, könnte man sich vorstellen, dass man mehrere Fenster(handles) in der Threadklasse hinterlegt, so dass evtl. sogar jeder Signaltyp (wenn man mal mehr als nur einen Counter hat) theoretisch an ein anderes Fenster gesendet werden kann. Damit könnte man dann sogar realisieren, dass eine von TEdit abgeleitete Klasse selbst auf eine Message aus dem Thread reagiert und die Anzeige übernimmt, ohne dass in einem zentralen Formular eine Verteilungslogik her müsste. Einfach direkt an diese Klasse senden lassen.
Ich denke schon, dass es sich langfristig sehr lohnen würde, sich mit Threads zu beschäftigen. Viele machen sich bei dem Thema auch oft zu viel in die Hose; es ist wirklich nicht kompliziert, wird aber wie so oft heuertage durch eine ganz tolle hochtrabende Begriffswelt verklausuliert, die erstmal nur erdrückend aussieht. Die Konzepte hinter Synchronizing, Locking, Priority, WaitForSingleObject und so weiter sind an sich recht trivial - zumindest wenn man nicht grad letzte Woche seinen ersten Compiler gekauft hat
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)