Nema na cemu, mislim da ti to i jeste najbolji pristup, sto ti je i savkic vec pisao.
Bukvalno, uprosceno, imas dugme "Obradi" na ciji pritisak pocinje neka duza obrada podataka koja ti "zakljuca" main (UI) formu, pa ti aplikacija deluje blokirano ("zamrznuto"). Promenis logiku da se pritiskom na dugme samo dugme disable-uje (kako ne bi moglo ponovo da se klikne), i da se pokrene poseban thread koji ce da odradi obradu - za to vreme tvoja aplikacija normalno odgovara na komande korisnika, nije zamrznuta. Po zavrsetku obrade, thread signalizira main (UI) formi (thread-u) da je obrada gotova (PostMessage, TEvent, sta god), i ti prikazes podatke (i po potrebi ponovo enable-ujes dugme).
Jedino na sta treba ovde obratiti paznju jeste da neka druga komanda ne moze da poremeti reakciju na zavrsetak thread-a - recimo ako neko u medjuvremenu izotvara neke druge forme (dok tvoj thread "obrada" jos uvek radi, jer forma vise nije zakljucana/blokirana, pa moze da se po njoj klikce), kad jednom thread zavrsi moras misliti na to sta ce se dalje desiti - ako saljes poruku koja ce za rezultat imati upisivanje neke vrednosti u npr. edit komponentu main forme, pritom je i fokusirajuci, to moze biti problem ako preko toga imas jos neke (u medjuvremenu) otvorene forme, pa tvoja edit komponenta ne moze da prihvati fokus (jer je i cela forma u pozadini, neaktivna), cak mozes dobiti i exception (npr. "cannot focus disabled window", ili tako nesto), sto sigurno nije prijatno za krajnjeg korisnika, niti pohvalno za tvoju aplikaciju.
Thread-ovi mogu biti jako zgodni, ali su u pocetku mozda malo tezi za shvatanje jer razbijaju uobicajeni "linearni" tok izvrsavanja programa, gde u svakom trenutku znas sta ce se, i kada desiti. Kod thread-ova to ne vazi, i jedino je bitno da kad se nesto desi (kad kog to bilo), ti budes spreman da na to adekvatno reagujes, bez ugrozavanja/remecenja stabilnosti programa, i njegovog trenutnog stanja - koje se verovatno promenilo od trenutka pokretanja thread-a, jer to i jeste sustina, da vise stvari moze da se izvrsava paralelno, ali je programer taj koji mora viditi racuna da to izvrsavanje bude uskladjeno, da paralelna desavanja ne uticu negativno jedno na drugo.
p.s. Eh, sad sam tek primetio da si ubacio Application.ProcessMessages(), to je vec nesto sto treba zdusno izbegavati... :/ Da, u vecini slucajeva ce mozda raditi posao, ali je malo aljkav pristup programiranju. Ne kazem, nekad treba odraditi posao u roku, uzeti novac i preziveti mesec, ali kad mogucnosti dopustaju, izbegavati.
Zasto? Zato sto isto razbija linearni/ocekivani tok programa, ali kada se to (naj)manje ocekuje. Npr, imas gorepomenuto dugme "Obrada" na koje se pokrece neko procesuiranje, i uglavnom je tad cela aplikacija "zamrznuta" dok se procesuiranje ne zavrsi - sto znaci da inace nema nikakve potrebe da disable-ujes dugme (iako je to mozda dobra praksa, ali je u ovom slucaju nepotrebno).
Medjutim, kad u toku procesuiranja pozivas Application.ProcessMessages(), ti dozvoljavas formi da u medjuvremenu odgovara na Windows poruke (pa ona vise nije "zamrznuta"), ali to ima i jedan sporedni efekat - tada ce korisnik moci ponovo da klikne na dugme "Obrada" (koje prethodno nije imalo potrebe da bude disable-ovano), pa ce se procedura za obradu pokrenuti ponovo (dok se prethodna jos nije zavrsila), sto tek moze imati neocekivane efekte.
Ovo je samo jedan banalan primer (evo ovde upravo pricaju o tome --
http://delphi.about.com/od/obj...-processmessages-dark-side.htm), mozes ih naci jos, svejedno vredi istraziti malo i na tu stranu. Ponavljam, generalno bi to trebalo izbegavati, ali kako je realan zivot obicno (bar) malo van teorije, jedino ti znas sta ti u datoj situaciju radi posao, i da li cilj opravdava sredstvo. Jedino bi dobro bilo da budes svestan da to nije najsretnije resenje.