Reaktion auf Click() für eine Form unterbinden.
-
Meiner Meinung nach wäre es sinnvoller, dafür zu sorgen, dass das Formular weiterhin die Botschaften verarbeitet...
Gruß
KK
-
Killer-Kobold schrieb:
Meiner Meinung nach wäre es sinnvoller, dafür zu sorgen, dass das Formular weiterhin die Botschaften verarbeitet...
Stimmt. Derartige Aufgaben gehöre eigentlich ohnehin in einen separaten Thread.
-
Killer-Kobold schrieb:
Meiner Meinung nach wäre es sinnvoller, dafür zu sorgen, dass das Formular weiterhin die Botschaften verarbeitet...
Prinzipiell ja. Es ist jedoch in einem gewissen Rahmen eine konzeptionelle Frage. Wenn im FormClick Verarbeitungen laufen, welche während der vom Threadsteller angesprochenen Sicherung sowieso nicht zur Verfügung stehen müssen, kann man die Methode doch auch einfach aushängen!?
Wie sagt ihr eigentlich zu dieser Variante:
FormXYZ->Enabled= false;?
-
Danke für Eure Antworten.
Ich denke ich werde einiges ausprobieren.
Das Formular ist lediglich ein Info-Fenster mit einem Button "Siecherung abbrechen" und informiert dass die Sicherung noch läuft.Neue Thread ist etwas aufwendiger und vielleicht in diesem Fall nicht nötig oder doch?
-
Ich wünsche Euch allen schöne Ostern!
-
Ebenso, Danke
-
aesse schrieb:
Das Formular ist lediglich ein Info-Fenster mit einem Button "Siecherung abbrechen" und informiert dass die Sicherung noch läuft.
Neue Thread ist etwas aufwendiger und vielleicht in diesem Fall nicht nötig oder doch?
Doch. Gerade wenn du dem Benutzer die Möglichkeit geben willst, den Prozeß zu unterbrechen, müssen UI und Sicherung parallel ablaufen - wie soll das denn sonst funktionieren?
-
Hallo Audacia,
in der Verarbetingsschleife bei der Sicherung wird immer ein Wert der zuständigen Variabelen abgefragt, mit Click auf den Button "Sicherung abbrechen" wird der Wert auf "false" gesetz und die Sicherung somit unterbrochen. Es funktioniert soweit, nur bei der Sicherung von größeren Dateien kommt nach dem Click auf den Button oder bei der Verschiebung des Formulars zu etwas unangenehmen Verzögerungen.
-
aesse schrieb:
in der Verarbetingsschleife bei der Sicherung wird immer ein Wert der zuständigen Variabelen abgefragt, mit Click auf den Button "Sicherung abbrechen" wird der Wert auf "false" gesetz und die Sicherung somit unterbrochen.
Das ist schon richtig so. Es ändert aber nichts daran, daß der Sicherungsprozeß im UI-Thread nichts zu suchen hat.
aesse schrieb:
Es funktioniert soweit, nur bei der Sicherung von größeren Dateien kommt nach dem Click auf den Button oder bei der Verschiebung des Formulars zu etwas unangenehmen Verzögerungen.
Abgesehen davon, daß das äußerst unprofessionell wirkt, kann es dazu führen, daß der Benutzer deiner Anwendung, da diese nicht mehr auf Nachrichten reagiert, von Windows die Meldung "diese Anwendung reagiert nicht mehr" bekommt und versucht ist, sie zu terminieren.
Grundsätzlich gehört alles, was länger als eine halbe Sekunde verzögert, in einen separaten Thread.
-
Ich stimme den anderen zu, was einen separaten Thread angeht. Alternativ kannst du in deine Sicherungsroutine (in die Schleife) das Zeilchen
Application->ProcessMessages();
einfügen. So werden die Messages in der Warteschlange (falls vorhanden) bei jedem Durchlauf abgearbeitet, und es kommt nicht zu den ungewollten Verzögerungen.
Allerdings frag ich mich, wieso du anfangs die OnClick-Methode ausschalten wolltest, obwohl du sie ja eigentlich brauchst (Sicherung abbrechen).
-
WebFritzi schrieb:
Allerdings frag ich mich, wieso du anfangs die OnClick-Methode ausschalten wolltest, obwohl du sie ja eigentlich brauchst (Sicherung abbrechen).
Das habe ich auch nicht verstanden.
WebFritzi schrieb:
So werden die Messages in der Warteschlange (falls vorhanden) bei jedem Durchlauf abgearbeitet, und es kommt nicht zu den ungewollten Verzögerungen.
Höchstens etwas seltener. Siehe hier:
aesse schrieb:
Es funktioniert soweit, nur bei der Sicherung von größeren Dateien kommt nach dem Click auf den Button oder bei der Verschiebung des Formulars zu etwas unangenehmen Verzögerungen.
Während des Bearbeitens größerer Dateien wird er nicht Application->ProcessMessages() aufrufen können.
Im Übrigen ist Application->ProcessMessages() als Scheduling für arme Leute nur bedingt tauglich: es führt unnötige Abhängigkeiten ein (warum muß der Code, der die Sicherung durchführt, wissen, daß er in einer VCL-GUI-Anwendung ausgeführt wird?), die nicht nur die Portierung (Application->ProcessMessages() funktioniert nur in C++Builder-Anwendungen), sondern auch die Wartung und die Wiederverwendung des Codes erschwert (z.B. wäre es überflüssigerweise nötig, den Code zu ändern, wenn die Sicherung zusätzlich noch über ein Kommandozeilenprogramm durchgeführt werden können soll). Zudem wird man damit die Blockade des UI-Threads nicht beseitigen, sondern nur verringern können.
Deshalb: nimm einen separaten Thread. Alles andere ist hier unangemessen.
-
Danke,
Ihr habt mich überzeugt.
Ich werde mit dem Thread versuchen. Schöne Grüße!