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

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

[BUG]

Zitat von Aphton:

schlechtes Design anwendet (GUI/Logik Trennung) und wenn man schon Dirty-Dinge macht

Das mit der Trennung kriegt man auch noch hin. Man könnte ApplicationRefresh/keepAlive ja auch in einem Callback (á la onProgress) aufrufen.

Zitat von Aphton:

Schlag was was besseres vor.

Delphi-Quellcode:

procedure 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;

@DSCHUSCH: Coole Lösung

[DSCHUCH]

Blumen auch an Himitsu, er hat die Grundidee erarbeitet.

Ja - so habe ich das jetzt auch testhalber in Verwendung - callbacks, welche die Application am Leben halten, ohne das man sonstwas bauen muß. Die Anwendung ist geblockt aber reagiert für Windows (kein Hang), Nutzereingaben werden ignoriert, genauso wie es sein muß. Das alles ohne Disable/Enable und wtf ever für einen blödsinnigen, aufwendigen Nudelcode, der sowieso nur zu Nebeneffekten führt. (zB da durch Application.ProcessMessages ja auch Timer aufgerufen werden können).

Funktionieren tut das aber auch nur aus dem Hauptthread heraus. Die Anwendung muß also nach wie vor vernünftig designed sein.

Achtung - beim Testen im Debugger verhält sich das anders, als wenn die Anwendung ohne Debugger läuft - Delphi hält die Debug-Anwendung hier sicher selbst am Leben, damit Windows nicht meckert "Anwendung reagiert nicht".

[DSCHUCH]

Kann dies mal jemand auf Windows Vista/XP/8 probieren? Die Testanwendung bietet ja die Option mit dem Radiobutton die Funktion an- und abzuschalten.

[anro78]

Zitat:

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

Aber genau das macht man, wenn man eine Anwendung robust entwickeln will, alles andere ist doch nur Herumdoktern an den Symptomen. Was machst du denn z.B. bei einer SQL-Abfrage, die einige Sekunden dauert? Dann hast du gar keine Möglichkeit ApplicationRefresh aufzurufen! Die Implementierung von Threads zur Ausführung von Abarbeitungs-Jobs außerhalb des VCL-Mainthreads ist nun wirklich kein Teufelszeug und innerhalb weniger Minuten implementiert. Man hat die Möglichkeit, den Nutzer über eine Statusanimation entweder definiert (Progress) oder undefiniert (Marquee) über den Fortschritt zu informieren, die Anwendung bleibt weiterhin reaktionsfähig (kann z.B. minimiert oder das Fenster verschoben werden). Und eine Funktion, die sämtliche Top-Level-Controls in einem Fenster während der Abarbeitung sperrt ist auch schnell geschrieben.