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.

[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

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.

[himitsu]

Zitat von Fukiszo:

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.

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.