User klicken unterbinden während Querry läuft

[DeddyH]

Zitat von Luckie:

Und so lange Operationen verlagert man üblicherweise in einen Thread.

Nur was soll der in diesem Fall nützen? Wenn der Server so lange braucht, um Daten zu liefern, dann braucht er eben so lange.

[Luckie]

Aber dann reagiert das Fenster wem falls noch und der Benutzer kann es bei Seite schieben oder minimieren oder man kann eine Animation einblenden. Zumindest hat der Benutzer nicht mehr den Eindruck, das Programm wäre abgestürzt.

[gsh]

Zitat von Jumpy:

Nee das hat schon gepasst, da ich hinterher ja Enabled wieder auf true setze. Aber es hat nix gebracht. Wie zuvor kann man wild auf Buttons klicken, ohne das zunächst was passiert, aber wenn die Querry dann fertig geöffnet ist und ein Ergebnis zurückgebracht hat, passiert alles, was nach drücken der Buttons geschehen sollte.

Was den Eindruck des Absturzes angeht, so ist das ja genrell ein Problem, da ja wie geschildert nix passiert, während die Querry läuft und jeder Knopfdruck scheinbar ignoriert wird, so dass ein User denken könnte, das Prog. wäre abgestürzt. Aber damit muss man bei langen Abfragen halt leben. Was halt nur stört ist, das evtl. Buttonklicks während der "Todzeit" des Progs trotzdem irgendwie registriert und dann anschließend ausgeführt werden.

Weitere Ideen gerne willkommen. Vllt. ist ja wirklich der Zeitpunkt bzw. das Ereignis wichtig, bei dem alles wieder aktiviert wird.

Jumpy

Mach mal ein Application.ProzessMessages; bevor du das Form wieder aktivierst. Schöner wäre es das ganze in einen Thread auszulagern.

[Jumpy]

Erstmal danke für das rege Interesse und
hier mal der momentane Code, der nicht funzt wie gesagt Quelle = TADOQuerry:

Code:

procedure TSelector.acOpenExecute(Sender: TObject);
begin
  if Quelle.State in [dsedit,dsinsert] then Quelle.Post;
  Quelle.Close;
  pnltab.Caption:= 'Bitte warten';
  self.Repaint;
  Quelle.SQL.Clear;
  Quelle.SQL.Text:= Memo1.Lines.Text;
  try
    self.Enabled:=false;                //Disabled
    Application.ProcessMessages;
    Quelle.Open;
    Application.ProcessMessages;
    pnltab.Caption:= '';
  except
    on e: exception do
      begin
      pnltab.Caption:= e.message;
      Application.ProcessMessages;
      self.Enabled:=true;
      end;
    end;
  Application.ProcessMessages;
  self.Enabled:=true;                       //enabled
end;

Mit self.enabled scheints da noch komischer zu werden. Manchmal (nicht immer) wird die Anzeige der Daten im Grid nicht aktualisiert. Erst wenn man aus dem Fenster klickt, dann wieder rein, ist es auf einmal da. Luckie scheint recht zu haben, dass das disablen des ganzen Forms "gefährlich" ist.

Hab Alternativ auch mal nur einen Button disabled und den dann gedrückt während die Query lief. Nachdem mir die Daten angezeigt wurden, ging das Fenster auf, dass der Button öffnen sollte.

Was hat es mit der Botschafterwarteschlange auf sich. Kann man da was machen?

Das benutzen eines Threads überleg ich noch, allein um dem User mit einem Fortschrittsbalken Aktivität vorzugaukeln. Das sollte aber unabhängig von dem jetzigen Problem sein, dass ich erst mal gelöst haben will, nämlich das ignorieren von User-Aktionen während die Daten aus der Datenbak geholt werden.

Jumpy

[DeddyH]

Du könntest ein Panel(alClient) auf die Form legen, da die Controls hinein und dann das Panel disablen statt des Formulars. Und zur Botschaftswarteschlange: Windows legt die Botschaften, die an Dein Fensterhandle gehen, in dieser Schlange ab. Während zeitintensiver Berechnungen wird diese aber nicht abgearbeitet (außer man ruft Application.ProcessMessages auf, was genau dies tut). So kann es dann kommen, dass Benutzereingaben erst mit einiger Verspätung Wirkung zeigen.

[Luckie]

Zitat von Jumpy:

Hab Alternativ auch mal nur einen Button disabled und den dann gedrückt während die Query lief. Nachdem mir die Daten angezeigt wurden, ging das Fenster auf, dass der Button öffnen sollte.

Das sollte nicht sein. Deaktivierte Schaltflächen erhalten keine Klick-Nachrichten.

[Jumpy]

Zitat von Luckie:

Das sollte nicht sein. Deaktivierte Schaltflächen erhalten keine Klick-Nachrichten.

Genau das macht mich ja auch so stutzig und läßt mich vermuten, das der Versuch mit einem Panel wie von DeddyH vorgeschlagen auch nix bringen wird.

Hab mal einfach nach dem
Quelle.Open;
showmessage('AAAAhhhhrg');
eingebaut.

Und siehe da. Das ganze rumgeklicke wird ignoriert. Ich vermute daher, dass die Klicks in der Botschafterschlange landen, dann geht aber das modale showmessage auf. Nun werden alle Klicks abgearbeitet, laufen aber ins leere, wenn sie nicht gerade die OK-Taste des Messagefensters treffen (wg. modal) und das wars dann.
Ich denk jetzt ernstahft darüber nach ein modales Mini-Form aufzumachen, dass die Klicks abfängt und es dann wieder zuzumachen, aber das kann es doch nicht sein...

[s.h.a.r.k]

Dieses Form.Enabled auf False setzen ist nicht gerade sehr schön imho. Wenn es wirklich längere Operationen sind (>2 Sek.) dann sollte man sich wahrlich überlegen das ganze in einen Thread auszulagern, so wie Luckie gesagt hat. Ebenso sollte man sich überlegen, so wenig wie möglich zu disablen oder evtl. gleich ein modale Ladeform einzubauen. Stellt dir mal vor du bist der User und bekommst sehr wenig Feedback darüber, was deine Anwendung denn gerade macht.

Stell dir vor Windows kopiert Dateien ohne den Kopier-Dialog!? Was würdest denn davon halten? Und was würdest davon halten, wenn Windows komplett anhält (bzw. sich disabled) bis so ein Kopiervorgang abgeschlossen ist?! Mir ist schon klar, dass der Vergleich aufgrund der Multitaskfähigkeit von Windows etwas hinkt, aber ich denke es ist klar, was ich meine

Der Startup großer Anwendungen wird bei mir z.B. immer in einen Thread ausgelagert. Dort werden alle Objekte erzeugt, Daten aus der DB geladen etc. Von diesem Thread aus werden Nachrichten an einen Ladescreen (Stichwort: Splashscreen) geschicht und so bekommt der User Feedback über den aktuellen Fortschritt.

[DeddyH]

Hast Du das Disablen auch vor das Öffnen der Query gesetzt?

[Jumpy]

Zitat von DeddyH:

Hast Du das Disablen auch vor das Öffnen der Query gesetzt?

Ja. Aber ich hab es innerhalb des try-Blocks gesetzt. Als letzten Versuch hab ich es mal davor gesetzt und auf einmal klappt es. Keine Ahnung warum das einen Unterschied macht.
Wenn einer 'ne Idee hat wieso, her damit, denn ich lerne gerne neues.
Hab jetzt auch wieder die Version genommen, wo nur die ActionList suspended wird.

Code:

procedure TSelector.acOpenExecute(Sender: TObject);
begin
  if Quelle.State in [dsedit,dsinsert] then Quelle.Post;
  Quelle.Close;
  ActionList1.State:= asSuspendedEnabled; //hier ist es jetzt
  pnltab.Caption:= 'Bitte warten';
  self.Repaint;
  Quelle.SQL.Clear;
  Quelle.SQL.Text:= Memo1.Lines.Text;
  try
    //hier war es vorher
    Quelle.Open;
    pnltab.Caption:= '';
  except
    on e: exception do pnltab.Caption:= e.message;
  end;
  Application.ProcessMessages;
  ActionList1.State:= asNormal; //hier wieder alles möglich
end;

Damit ist mein Problem gelöst, das der User keine Buttons mehr klicken kann. Gleichzeitig ist aber das Form noch enabled was mir auch lieber ist (und z.B. Verschiebbar). Ich werd jetzt morgen noch einen Thread dafür aufsetzen, damit ich dem User Fortschritt vorgaukeln kann und bin happpy.

Danke für die viele Hilfe bei meinem ertsen Post und Problem hier. Wird bestimmt nicht das letzte bleiben, da ich gerade erst mit Delphi angefangen hab,
Jumpy.