ProcessMessage
s ruft in einer Schleife ProcessMessage auf (bis es nichts mehr gibt)
aber auch Application.Run führt ProcessMessage aus, was dann übrigens normalerweise deine Events (Button-Click, Tastatur, Maus, Timer, Paint, Synchronize, ...) ausführt.
Also
nach deinem Event wird sowieso ProcessMessage ausgeführt
und wenn dein Event zu lange braucht, dann "kannst" Du zwischendurch auch ProcessMessage (Eins / das Erste) oder ProcessMessages (Alles) ausführen und die angefallenen Arbeiten vorziehen.
Zitat:
Gibt es eine ProcessMessages variante die nicht CheckSynchronize aufruft?
Nicht, dass ich wüsste.
Bei uns in der Firma hatte ich mal ein ProcessDrawMessage eingebaut (aber so ganz richtig kann es nie funktionieren),
da hab ich versucht mit PeekMessage/GetMessage nur Messages rauszuholen und zu verarbeiten, die keine Tastatur, Maus oder Timer sind und auch das Synchronize ist nicht drin,
um nur Zeichen- und Speicheroperationen ausführen zu lassen, aber eben keine anderen Aktionen vorzeitig reinrutschen zu lassen.
Ich habe in aktuelleren Projekten alle langen Arbeiten in threads mit ther TAnyonymousThread Klasse(
https://community.embarcadero.com/bl...tification-127) ausgelagert und Sperre die Oberfläche mit einem Halbtranparenten Rechteck auf dem ein Anyindikator liegt...
Aus gründen die ich nicht ganz verstehe...bewegt sich der Anyindicator nur wenn ich in dem Thread Synchronize mit processmessages aufrufe...
Insbesondere auch Timer und andere Message gesteuerte sachen scheinen sich nicht mit threads zu vertragen, aber zum verzögerten starten von aktivitäten brauche ich dann halt ab und zu mal eine timer der z.b. 3 sekunden nach dem ersten sichtbarwerden des Formulars loslegt...
Ich sehe gerade, dass TAsyncProgress mir vielleicht geholfen hätte...