Hilfe application.ProcessMessages bei Win 10

[Fukiszo]

himitsu verstehe mich bitte nicht falsch.

repeat
processmessages;
until irgendwas:

egibt das das formular einfriert, richtig?

repeat
sleep(20);
processmessages;
until irgendwas:

egibt das das formular noch reagieren kann, zum beispiel ein "Abbruch" Knopf betätigen, richtig?

ich schau mir mal dein delay link an.

grüße

[EWeiss]

Zitat:

repeat
processmessages;
until irgendwas:

egibt das das formular einfriert, richtig?

also das friert nie ein.

Delphi-Quellcode:

procedure WinProcessMessages;
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;

Delphi-Quellcode:

repeat
WinProcessMessages;
until irgendwas;

sollte mich auch wundern..
Mit Sleep bremst du die anderen Messagen nur aus.
Warum das bei W10 Probleme machen kann? Keine Ahnung.

Zitat:

Im OnShow ist das ungünstig plaziert.

Dito und das wird auch sein Problem sein.

gruss

[achi 3.0]

Danke für die ganzen Antworten. Hatte auch schon mal gelesen, das application.ProcessMessages irgendwie böse ist aber selbst damit nie ein Problem gehabt bis zu einem Update von Windows 10. Ab jetzt sind aber alle Windows 10 Versionen betroffen außer ich installiere Windwos 10 von einer alten CD.

Das mit der repeat schleife habe ich nun mit einem Timer gelöst, was mir jedoch nicht erklärt was Windows nun anders macht.
Einzig mit eine Sache bekomme ich nicht hin. Wenn ich eine Datei mittels IdHTTP1 übertrage will ich während der procedure TForm2.IdHTTP1Work eine Progressbar laufen lassen. Diese wird aber nicht angezeigt ohne application.ProcessMessages. Habt Ihr eine Idee wie ich es hinbekomme das die Progressbar während der procedure weiter aktuallisiert wird.



ProgressBar1.max := AWorkCountMax;

procedure TForm2.IdHTTP1Work(Sender: TObject; AWorkMode: TWorkMode;
const AWorkCount: Integer);
begin
ProgressBar1.position := AWorkCount;

end;

[haentschman]

Hallöle...
ProgressBar1.Repaint ..oder so. Da wird nur die einzele Komponemte neu gezeichnet statt der Application.ProcessMessages.

[achi 3.0]

Hallöle zurück.

Danke für den Tip. Werde es direkt mal ausprobieren.

[himitsu]

Zitat von Fukiszo:

egibt das das formular einfriert, richtig?

Das nicht, aber das Sleep friert immer wieder kurz alles ein und sorgt auch dafür, dass "tu was" länger braucht.

Eine reine Warteschleife, die nur Messages verarbeitet, die garf gern kurz einfrieren, wenn gerade keine Messages vorhanden sind.
Gerade das wurde in dem Delay von Hagen optimiert, also statt einen Sleep wird dort mit WaitFor auf den Timeout gewartet oder bis eine Message ansteht.

[Fukiszo]

Ja habs grad auch getestet, ihr habt recht.
Ich nutz meist SleepEx() damit der sleep bei IO automatisch aufhört (nicht wegen "system warte mal und gönn dir was")
edit:
die delay() funktion ist gut, die zweite variante ähnelt stark einer meiner gebastelten sachen.

[himitsu]

Ich bau auch ab und an mal ein Sleep(0); ein, z.B. wenn ich direkt nach TThread.Create den Thread gestartet haben möchte.

Gibt auch irgendeinen Assemblerbefehlt dafür, aber den vergesse ich eh immer.
Sleep(0) sagt ja einfach nur "so, ich bin fertig ... den Rest meines TimeSlots brauch ich nicht mehr. Also Windows, du kannst jetzt sofort erstmal die anderen Threads behandeln".

Den alten Ansatz des Kooperativen Multitasking führe ich gerne fort.