Verhindern von Mehrfachaktionen in der GUI

[eike42]

Moin zusammen,

ich war mir nicht sicher, wo das hier reinpasst, aber da es eher eine Frage zu Algorithmen an sich ist, schreibe ich es mal hier. Ggf bitte verschieben :)

Ich habe das folgende Problem, dass ich in meinem Programm öfters mal eine Aktion im onclick-Ereignis eines Controls ausführe, während der sämtliche anderen onclick-Ereignisse des Formulars bzw. der Applikation nicht funktionieren sollen. Logisch z.b., wenn ich meinen VirtualStringTree grade in ein File speichere, soll der Benutzer nicht parallel den Baum leeren oder ändern können. Ich habe bisher folgende Methoden gefunden, alle nicht ganz optimal, und wollte mal fragen ob es dazu eine generelle Vorgehensweise gibt, oder ob das jeder anders macht.

• Screen.Cursor:=crHourglass -> schön, aber User kann noch klicken.
• Form.enabled:=false -> User kann nicht mehr klicken, merkt aber nicht warum (der Cursor lässt sich dann nicht auf Sanduhr setzen).
• Irgendein modales Form mit z.b. TProgress-Control drauf -> hübsch, funktioniert aber bei relativ kurzen (1-5s) Aktionen etwas Overkill.
• Irgendein Untercontrol, z.B. TAdvPager oder TAdvOfficePager auf disabled false setzen -> Funktioniert und sieht gut aus, ist aber immer abhängig von der aktuellen

Form-Gestaltung.

Gibt es da noch etwas Besseres? Irgendwas Globales wie Application.blocked:=true o.ä.?

Vielen Dank und viele Grüße
Eike

[Sherlock]

Ist es für Dich wichtig, daß der User sieht, daß seine Aktion gerade nicht geht? Wenn nicht, kannst Du ja einen Boolean mitziehen, dessen Wert du in jedem Klickevent abfragst, wenn gerade noch eine Aktion läuft, wird halt das Event "übersprungen".

Sherlock

[s.h.a.r.k]

Führe eine private-Variable FBlocked ein und setze die so lange auf True, so lange du etwas machst. Danach eben wieder auf False. Das wäre zwar nicht wirklich sauber, aber ein gangbarer Weg.
// edit: unter sauber verstehe ich hier, dass der User darüber kein wirkliches Feedback bekommt, und wenn er auf einen Button klickt, dann eben einfach nichts passiert -> aber wieso. Daher folgendes dazu:

Betrachten wir das mal aus Usability-Sicht: was denkst du wäre für den User optisch sinnvoll? Ich löse das im Moment mit einem dunklen Overlay, sodass nichts mehr bedienbar ist. Darauf ist eine Schrift à la "Please wait...", wobei die Punkte animiert sind. So sieht der User, dass er nichts mehr machen kann, etwas warten soll und dank der animierten Punkte, dass das Programm sich nicht aufgehängt hat.

[eike42]

@Sherlock

Klar, der Benutzer soll ja wissen, dass der PC grade "beschäftigt" ist. Kennt er ja von Windows :wink:

Ich will ungern alle Event-Methoden ändern, vor allem da ich das Projekt (ziemlich gross) übernommen habe und bestimmt nicht überall auf einmal herumpfuschen will :wink:

@s.h.a.r.k

Stimmt, von der Methode hatte ich auch in irgendeinem Forum gelesen. Ja, der Nutzer soll optisch sehen, dass grade nichts geht. Ich würde mir auch blöd vorkommen, wenn plötzlich ein paar Sekunden lang meine Buttons nicht funktionieren...

Wobei mir wirklich eine Sanduhr als Cursor reicht - wie gesagt, der Benutzer weiss dann, dass grade nix geht.

[s.h.a.r.k]

Ich muss mal schauen, dass ich meine Overlay-Komponente nun endlich zu einer gewissen Reife treibe, dann kann ich das Ding auch veröffentlichen. Aber im Moment ists eher noch ein Prototyp, der aber schon ganz gut funktioniert.

Zitat:

Zitat von eike42 (Beitrag 1033783)

Wobei mir wirklich eine Sanduhr als Cursor reicht - wie gesagt, der Benutzer weiss dann, dass grade nix geht.

Überlege dir aber auch, dass du diverse Controls auch einfach disablen kannst, was an sich auch für ein gutes Feedback sorgt.

// edit
Da fällt mir aber auch gerade ein: warum duplizierst du nicht die Daten, die gespeichert werden sollen und speicherst dieses Duplikat dann im Hintergrund ab -> am besten eine Queue verwenden. Somit kann der User die Daten weiter bearbeiten und es wird alles brav im Hintergrund gespeichert. Nur so eine Idee, die mit einigem Aufwand verbunden ist :mrgreen:

[blackfin]

Zitat:

Ich löse das im Moment mit einem dunklen Overlay, sodass nichts mehr bedienbar ist. Darauf ist eine Schrift à la "Please wait...", wobei die Punkte animiert sind. So sieht der User, dass er nichts mehr machen kann, etwas warten soll und dank der animierten Punkte, dass das Programm sich nicht aufgehängt hat.

Genau so mache ich das auch normalerweise, das Overlay ist bei mir meist ein halbtransparentes "Effectspanel" aus dem "Bilennium Effects"-Pack.
Wenn du solche Komponenten nicht hast, kannst du auch z.B. ein halbtransparentes png über alles legen.

[s.h.a.r.k]

Wie geht das mit dem PNG?! :gruebel: TImages sind doch nur direkt auf der Form selbst (bzw. auf dem Parent des TImage) und nicht über allem, oder?!

Ich habe das bisher so gelöst, dass ich eine TForm habe und der eine Owner-Form übergebe. Dazu wird ein Hook installiert, der auf die Größen- und Positionsändeurngen des Owner-Forms reagiert. Somit wird der Overlay immer über den passenden Form gehalten. Entsprechend habe ich habe den Alpha-Wert der Form und kann sehr einfach zusätzliche Logik einbauen. Ebenso kann ich die Overlay-Form ableiten und meine eigene Logik mit einbauen, so wie ich vorher schon beschrieben habe.

[himitsu]

Von welchen Zeiteinheiten reden wir hier denn?

Zitat:

Ich habe das folgende Problem, dass ich in meinem Programm öfters mal eine Aktion im onclick-Ereignis eines Controls ausführe, während der sämtliche anderen onclick-Ereignisse des Formulars bzw. der Applikation nicht funktionieren sollen

Standardmäßig reagiert die IDE und somit alle anderen Ereignisse nicht, wärend z.B. ein OnCLick-Ereignis earbeitet wird.
(es sei denn man umgeht es über Application.ProgressMessages)

wenn es nur um ein paar Sekündchen geht, dann Screen.Cursor ändern und einfach machen (ohne eine zwischenzeitliche Behandlung der Messages) und schon gibt es keine Probleme. :angel:

[s.h.a.r.k]

Vielleicht sind ja auch Threads im Spiel?! Ich denke, dass die schon eine recht allgemein Diskussion ist, daher ist es ja an sich von der Zeitspanne relativ unabhängig.

[eike42]

Zitat:

Zitat von himitsu (Beitrag 1033789)

Standardmäßig reagiert die IDE und somit alle anderen Ereignisse nicht, wärend z.B. ein OnCLick-Ereignis earbeitet wird.
(es sei denn man umgeht es über Application.ProgressMessages)

Wenn es so wäre hätte ich ja keine Probleme! Aber (zumindest bei mir) kann man einen Doppelklick auf einen Button machen und hat 2 Threads parallel. Vielleicht eine Compilereinstellung?

[s.h.a.r.k]

Zitat:

Zitat von eike42 (Beitrag 1033791)

Vielleicht eine Compilereinstellung?

Das ist eher unwahrscheinlich, da während der Abarbeitung deines Codes keinerlei Messages abgearbeitet werden. Die Form dürfte eigentlich auch nicht bedienbar sein.

[eike42]

Ja, ich habe es grade an einem Beispielprojekt getestet und es ist wie du sagst. Das Form ist blockiert, solange meine onclick läuft.

Komischerweise ist es in meinem "grossen" Projekt wirklich so, dass man mehrfach klicken kann. Ich mache dort ziemlich viel mit sehr vielen Objekten, vielleicht liegt es daran, dass Delphi dann verschiedene Threads startet?

[Namenloser]

Delphi startet nie von sich aus verschiedene Threads. Wahrscheinlich wird irgendwo während der Verarbeitung Application.ProcessMessages aufgerufen.

[himitsu]

Wie gesagt, wenn man die Messagebearbeitung irgendwo "manuell" Abarbeitet, dann werden diese auch zwischendurch abgearbeitet.

> Delay, Application.ProcessMessages und Co.

Zitat:

Zitat von NamenLozer (Beitrag 1033800)

Delphi startet nie von sich aus verschiedene Threads. Wahrscheinlich wird irgendwo während der Verarbeitung Application.ProcessMessages aufgerufen.

Wie du an deinem Test ja gemerkt hast.

[s.h.a.r.k]

Oder du nutzt Komponenten die intern Threads starten bzw. Application.ProcessMessages ausführen. Sinnvoller ist es aber an sich schon, dass man selbst Threads startet und dem User entsprechend Feedback gibt. Klar, ist es mehr Aufwand und muss immer abgeschätzt werden.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1033801)

Zitat:

Zitat von NamenLozer (Beitrag 1033800)

Delphi startet nie von sich aus verschiedene Threads. Wahrscheinlich wird irgendwo während der Verarbeitung Application.ProcessMessages aufgerufen.

Wie du an deinem Test ja gemerkt hast.

Darf man fragen, was damit gemeint ist?

[himitsu]

Zitat:

Zitat von NamenLozer (Beitrag 1033891)

Darf man fragen, was damit gemeint ist?

Tschuldschung ... sprach den TE an, welcher ja in seinem Test nun auch festgestellt hatte, daß da "eigentlich" nichts paralell läuft.

Zitat:

Zitat von eike42 (Beitrag 1033799)

Ja, ich habe es grade an einem Beispielprojekt getestet und es ist wie du sagst. Das Form ist blockiert, solange meine onclick läuft.

[Namenloser]

Ah, ok :)
Ich bezog mich übrigens auf den 2. Absatz im gleichen Beitrag:

Zitat:

Komischerweise ist es in meinem "grossen" Projekt wirklich so, dass man mehrfach klicken kann. Ich mache dort ziemlich viel mit sehr vielen Objekten, vielleicht liegt es daran, dass Delphi dann verschiedene Threads startet?

[Mschmidt]

Grunsätzlich ist es ratsam, den Anwender zu informieren - das z.b. die nächste halbe Stunde ein File gesichert wird.:-)
Ich behaupte es ist falsch - dabei mögliche Aktivitäten sei es Menüs oder Buttons zu deaktivieren. Das ist zwar syntaktisch
korrekt - erzeugt aber u.U. einen nicht mehr zu überblickenden Overhead. Eine gangbare alternative wäre das in (a)synchrone Thread auszulagern.
Alternativ über ein separaten modalen - Dialog. Da dieser dann den Focus und somit auch alle onClick() Ereignisse erhält,
ist die Frage ob Button sperren oder nicht, oder Variable abfragen zweck- und sinnlos.
Und da bei guter Programmierung der Code nicht am GUI hängt, ist es doch egal, von wo er aufgerufen wird, gell?

:-mschmidt

[igel457]

Ich würde folgendes machen: Bevor die Aktion ausgeführt wird, wird eine Kopie der Arbeitsdaten im Speicher erzeugt. Während dieses Prozesses wird ein modaler Dialog eingeblendet, der dem Nutzer mitteilt, dass das Programm gerade am Arbeiten ist.

Mit der Kopie der Arbeitsdaten kannst du nun in einem eigenen Thread machen was du möchtest (zum Beispiel auf die Festplatte schreiben, komplexe Berechnungen Anstellen etc.) und der Benutzer kann trotzdem (abgesehen von der Kurzen Unterbrechung oben) weiterarbeiten. Diese Vorgehensweise ermöglicht es dir auch mehrere der Aktionen gleichzeitig auszuführen.

[s.h.a.r.k]

Ich denke, es hängt immer von der Dauer der Aktion und dem Programm an sich ab. Wenn das Programm nur für Sicherungen da ist, dann ist es sinnvoll alles zu deaktivieren oder einen modalen Dialog einzublenden. Wird es aber sehr stark frequentiert, weil Cheffe immer was wissen will, dann sollte man tunlichst alles im Hintergrund laufen lassen. Ebenso kommt es hier aber darauf an, ob es nur diese Anwendung gibt, oder ob nicht noch eine Server-Anwendung im Hintergrund (auf einem anderen Server) läuft.

Zitat:

Zitat von blackfin

Wenn du solche Komponenten nicht hast, kannst du auch z.B. ein halbtransparentes png über alles legen.

Mich würde aber immer noch interessieren, wie das funktionieren soll?! :gruebel: