P
Während deinem WaitForSingleObject blockierst du den Hauptthread deiner Anwendung, der auch z.B. für das das Verarbeiten von Nutzereingaben und das Neuzeichnen der Liste verantwortlich ist.
Du kannst ein neuzeichnen mit UpdateWindow() erzwingen -
allerdings "hängt" deine Anwendung immer noch.
Die sauberste Lösung wäre sicherlich, das Processing in einen Worker-Thread zu legen, der den Hauptthread mittels PostMessage von seinen Fortschritten benachrichtigt. Ist aber möglicherwese etwas komplex für nen Einsteiger.
Die nächstbeste Lösung wäre, sich einen Timer zu setzen, und den Handle z.B. aller 100 ms zu testen ohne zu warten ( WaitForSingleObject(pi.hProcess, 0) );
Ist aber recht aufwendig, da man zwischen den Aufrufen eine Menge Status "aufbewahren" muß (z.B. zumindest den Prozeßhandle)
Die am einfachsten zu implementierende, aber m.E. gefährlichste Lösung ist:
DWORD waitState;
while(1) // break on "Process terminated"
{
waitState = WaitForSingleObject(pi.hProcess, 100);
if (ok != WAIT_TIMEOUT)
break;
while (theApp.PumpMessage()); // theApp: see below
}
(theApp: meine CMyAp-Deklaration wird immer von einem extern CMyApp theApp gefolgt, so kann ich auf das Application-Object (was ja ein Singleton ist) immer nett zugreifen)
PumpMessage dispatcht genau eine anstehende Windows message, und gibt false zurück, wenn keine mehr ansteht. Ist insofern ungünstig weil:
a) ein "PumpMessage" nicht iun allen Umgebungen möglich/erlaubt ist, macht deine Lösung also weniger portabel
b) Man bekommt (oft verwirrende) Reentrancy-Probleme.
c) lokale message-Loops sind immer wieder ein Stolperstein
