Verhindern von Mehrfachaktionen in der GUI

[eike42]

@Sherlock

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

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

@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 von eike42:

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

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

[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 von himitsu:

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 von eike42:

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?

[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