Verhindern von Mehrfachaktionen in der GUI

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

[Namenloser]

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

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

[himitsu]

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

> Delay, Application.ProcessMessages und Co.

Zitat von NamenLozer:

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.