TApplication.OnIdle Event

[himitsu]

Wobei CheckSynchronize im ProcessMessage schon drin ist.
Und wenn dort nichts gemacht wurde und du es dann nochmal aufrufst, dann sollte ja nichts In der SynchronizeQueue drin sein (sonst würde OnIdle nicht aufgerufen), damit dürfte CheckSynchronize nicht machen und es würde keinerlei Unterschied geben.

[QuickAndDirty]

Zitat von himitsu:

Wobei CheckSynchronize im ProcessMessage schon drin ist.
Und wenn dort nichts gemacht wurde und du es dann nochmal aufrufst, dann sollte ja nichts In der SynchronizeQueue drin sein (sonst würde OnIdle nicht aufgerufen), damit dürfte CheckSynchronize nicht machen und es würde keinerlei Unterschied geben.

hm,
Ich versuche ja Processmessages zu vermeiden...nur beim Anyindicator und bei Laufbalken kommt es zum einsatz.
OMG....
Das erklärt warum damals Processmessages und Threads in Kombination so Wirre effekte hervorgerufen haben. Und ich Processmessages(und Timer) deswegen ziemlich abgeschafft habe.
Gibt es eine ProcessMessages variante die nicht CheckSynchronize aufruft?

[himitsu]

ProcessMessages 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.

[Uwe Raabe]

Ich weiß jetzt nicht, ob es an der Delphi-Version liegt, aber in 10.4 wird CheckSynchronize nur in Idle aufgerufen - nicht in ProcessMessages.
Idle wird allerdings in HandleMessage aufgerufen falls keine Message vorliegt. Das ist die Methode, die in einer Dauerschleife in Application.Run aufgerufen wird. Das bedeutet aber nicht, dass ständig Idle aufgerufen wird. Bei Done = True wird am Ende von Idle ein WaitMessage aufgerufen.

Zitat:

The WaitMessage function suspends the thread and does not return until a new message is placed in the thread's message queue.

Zu häufige Idle-Events (z.B. in manchen MDI-Apps) kann man übrigens mit Application.ActionUpdateDelay bändigen.

Es gibt noch ein paar andere Events, die CheckSynchronize mittels WM_NULL auslösen, aber die sind hier eigentlich nicht von Belang.

[QuickAndDirty]

Zitat von himitsu:

ProcessMessages 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...