Hilfe application.ProcessMessages bei Win 10

[achi 3.0]

Hallo allerseits,

ich hatte schon vor einiger Zeit einen Thread erstellt wo es um das einfrieren eines Programms bei Windows 10 ging. Leider konnte mir nicht geholfen werden. Ich habe aber weiter dinge ausprobiert und bin nun auf das Problem gekommen. Nur weiß ich nicht was hier bei Windows 10 anders gemacht wird.

Ich muss jedoch erwähnen, das es erst mit einem Update zu diesem Problem kam und ab nun jede Version das selbe aufweist.
Wenn ich bei Windows 10 einfach eine Form erstelle wo mittels Button1 die Form2 aufgerufen wird und in form2 on show folgendes rein schreibe:

repeat
....tue irgendwas

Application.ProcessMessages;
until exitbutton;
close;

Bei diesem code kann ich das Fenster nicht mehr schließen. Friert das Programm ein. Bei jedem Windows 7 oder älter funktioniert solch eine Hauptloop problemlos.
Hat jemand eine Ahnung was bei Windows 10 anders ist.
Bin euch für jede Hilfe dankbar, da mein Latein am ende ist.

Gruß

Achi

[uligerhardt]

Es ist allgemeines Delphi-Weistum, dass Application.ProcessMessages böse ist. Das beißt dich jetzt wahrscheinlich.
Kannst du die Schleife nicht anders gestalten? Wofür brauchst du das Application.ProcessMessages? Ist Form2 so eine Art Fortschrittsdialog?

[Bernhard Geyer]

Im OnShow ist das ungünstig plaziert.
Wollen wir sowas gleich nach dem öffnen machen, so legen wir einen Timer aufs Form der im OnShow gestartet wird oder wir senden uns eine WM_USER-Message.

Und ich weiß - Besser wäre ein Thread ...

[Fukiszo]

abgesehen davon das man es wie bereits erwähnt davon abuzraten ist,
versuche ein Sleep(20); in deine repeat schleife zu setzten damit die cpu nicht auf 100% läuft.

alternativ evtl so: (nicht den sleep vergessen!)
(ich weiß nicht ob's ne verbesserung oder verschlechterung zu deinem delphi ist!)

Code:

function MyProcessMessages : Boolean;
const
 WM_QUIT  = $0012;
var
 Msg : TMsg;
begin
 Result := False;
 while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do begin
  if Msg.Message = WM_QUIT then
  begin Exit end else begin
   TranslateMessage(Msg);
   DispatchMessage(Msg);
  end;
 end; Result := True;
end;

[Luckie]

Warum das nachbauen was Application.ProcessMessages selbst schon macht, nämlich die anstehenden Nachrichten abarbeiten?

[Fukiszo]

Dann lösch meinen Beitrag einen Hilfesuchenden zu Helfen. Geht schneller als Nachzufragen und man vom Thema abkommt.:thumb:

[himitsu]

Zitat:

versuche ein Sleep(20); in deine repeat schleife zu setzten damit die cpu nicht auf 100% läuft.

Delay http://www.delphipraxis.net/6620-delay.html :stupid:

Aber es macht auch keinen Sinn, den einmaligen Durchlauf noch künstlich mit einem Sleep/Delay zu verlängern.
Wenn wirklich viel zu tun ist, dann darf das Programm gern mal mit 100% laufen.

Aber wie die Messages behandelt werden ist letztendlich egal, wenn die Position wohl eher das Problem ist.

Zitat:

Im OnShow ist das ungünstig plaziert.

[Fukiszo]

Aber er wollte doch ein Einfrieren verhindern, weswegen ich Sleep() vorschlug. (nicht auf 100%)
Ja kann sein das es Delay() bei ihm heißen mag.
Da ich fast alle funktionen selbst bereitstelle kenn ich mich nicht zu 100% aus was wo tatsächlich existiert.

procedure Sleep(dwMilliseconds: DWORD); stdcall;
procedure Sleep; external kernel32 name 'Sleep';

Da hol ich mir mein Sleep() her, Delphi unabhängig. Ruft Delphi Version XYZ das gleiche auf? Ich weiß es nicht.

[uligerhardt]

Das hängt doch alles davon ab, was das "tue irgendwas" im ersten Post eigentlich ist. Da wäre Input vom OP hilfreich. :mrgreen:

[himitsu]

Zitat:

Zitat von Fukiszo (Beitrag 1391603)

Aber er wollte doch ein Einfrieren verhindern, weswegen ich Sleep() vorschlug. (nicht auf 100%)

Aber Sleep ist doch grade ein Befehl, mit dem Man das Programm absichtlich "einfriert. :lol:

Delay ist eine "eigene" Implementation, die Delphi nicht kennt.
Es verbindet Sleep mit einem Application.ProgressMessages, bzw. PeekMessage+DispatchMessage, damit der Code wartet, aber währenddessen dennoch Messages verarbeitet werden können.

[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...8-)

Delphi-Quellcode:

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:

Zitat von Fukiszo (Beitrag 1391615)

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. :stupid::zwinker:

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

Delphi-Quellcode:

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.