Verhindern von Mehrfachaktionen in der GUI

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