Application - Hang (Anwendung Reagiert nicht) bei längeren Operationen: Lösung?

[DSCHUCH]

Hallo,

ich habe jetzt mal noch ein wenig mit dem Problem experimentiert, das Windows immer meldet "Anwendung reagiert nicht mehr" sobald eine Operation länger als ein 3 Sekunden braucht (zumindest, wenn der Anwender noch einmal rumklickt).

Die Variante sämtliche längeren Operationen in Threads auszulagern finde ich ja von vorn herein absolut blödsinnig.

Die Erkenntnis: ich habe eine sehr sehr einfach Lösung gefunden.

In Kurz:

PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE);//Refresh Application dies zeichnet alles neu und hält die Anwendung am Leben, Nutzereingaben werden nicht bearbeitet. Ist im MSDN auch genauso beschrieben.
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Delphi-Quellcode:

while PeekMessage(Msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE) do;
while PeekMessage(Msg, 0, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE) do;

entfernt sämtliche Nutzereingabe, wodurch verhindert wird, das am Ende einer Schleife alles bearbeitet wird, do der Nutzer während der Wartezeit dumm rumgeklickt hat.

Damit ist eigentlich klar, das anstatt einem Application.ProcessMessages zum Refresh der Anwendung die obigen Befehle aufgerufen werden sollten.

Ich habe somit eine Funktion geschrieben:

Delphi-Quellcode:

procedure TForm11.ApplicationRefresh(RemoveUserInput: Boolean);
var Msg : TMsg;
begin
  PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE);//Refresh Application
  if RemoveUserInput then begin
     while PeekMessage(Msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE) do
           ;//User Mouse Removed
     while PeekMessage(Msg, 0, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE) do
           ;//User Key Removed
  end;
end;

Im Anhang eine ganz einfache Testanwendung. Was haltet Ihr davon?

[Aphton]

Jo, interessant!

Nenns KeepAlive / Unfreeze das kann man nun als eine andere Option zu Delay sehen ^^
Soetwas müsste man direkt in die oberste Basisklasse für sichtbare Controls packen damit man dann ganz einfach Self/Form1.KeepAlive/Unfreeze aufrufen kann.

[DSCHUCH]

Vor allem macht dies auch automatisch die notwendigen Zeichenoperationen (auch so im MSDN beschrieben).

Letzlich wird ja nicht einmal etwas verändert: die Nachrichtenwarteschlange der Anwendung bleibt, wie sie ist. Die Anwendung arbeitet anschliessend ganz normal weiter. Sämtliche Timer etc verhalten sich ganz normal.

Einzig Windows wird dadurch benachrichtigt, das die Anwendung kontrolliert die Nachrichtenwarteschlange abarbeitet.

[Aphton]

Ich habs mal ein bisschen umgeschrieben (Class Helper)

Delphi-Quellcode:

type
  // Control-F1: "Controls.TControl is the base class for all components that are visible at runtime."
  // .. und weil nur mit sichtbaren controls interagiert werden kann (onclick, ...), wirds frühestens bei TControl benötigt
  TControlKeepAliveHlp = class helper for TControl
  public
    procedure KeepAlive(const DropUserInput: Boolean = True);
  end;

procedure TControlKeepAliveHlp.KeepAlive(const DropUserInput: Boolean); // "DSCHUSCH"
var
  DummyMsg: TMsg;
begin
  PeekMessage(DummyMsg, 0, 0, 0, PM_NOREMOVE);
  if DropUserInput then
  begin
    while PeekMessage(DummyMsg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE) do;
    while PeekMessage(DummyMsg, 0, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE) do;
  end;
end;

[Bummi]

@Aphton ich sehe gerade nicht warum das ganze an einem Control hängen soll, es wird doch die Messagepipe mit 0, also für alle Handles abgefragt und (teil)geleert.

[Aphton]

Hmm..
Schlag was was besseres vor.

Das ist das, worauf ich auf die schnelle gekommen bin. Ich dachte mir, dass man, wenn man schon auf so Sachen wie delay() und eben dann keepAlive() ausweicht, schlechtes Design anwendet (GUI/Logik Trennung) und wenn man schon Dirty-Dinge macht - also in der GUI (sichtbare Controls -> Basisklasse Control) Berechnungen durchführt, dann kann man ja direkt hier mit keepAlive() ansetzen.