Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Processmessages nicht anwendbar. Was nun? (https://www.delphipraxis.net/124105-processmessages-nicht-anwendbar-nun.html)

Mattze 14. Nov 2008 12:12


Processmessages nicht anwendbar. Was nun?
 
Hallo,

application.processmessages kann ich an einer Stelle des Programmes nicht anwenden. (Warum, weiß ich nicht. Es müsste noch im Hauptthread sein!)
Nun möchte ich aber gerne einen Abbruch bei Bedarf erzeugen. (Click auf Abbrechenbutton und Setzen einer boolschen "Abbruchvariablen".)

Wie kriege ich das dann aber dort, wo ich abbrechen will (und kein processmessages funktioniert - Schutzverletzung) mit? Gibt's da was?

Gruß
Mattze

sirius 14. Nov 2008 12:18

Re: Processmessages nicht anwendbar. Was nun?
 
  1. ist Application.ProcessMessages sowieso immer schlecht
  2. musst du am Design deines Programmes etwas ändern (mehr kann ich nicht sage, ich kenn ja dein Programm nicht)
  3. Wenn du den Programmablauf sauber von der GUI getrennt hast, ist es ganz einfach

Fridolin Walther 14. Nov 2008 12:22

Re: Processmessages nicht anwendbar. Was nun?
 
Application.ProcessMessages ist schlecht. Letztlich emuliert Application.ProcessMessages das, was einem Threads viel einfacher bieten, wenn man denn seine Programmlogik sauber von der GUI getrennt hat. Wenn Deine Programmlogik natürlich überall im Code auf die GUI zugreift, ist das eher unschön, weil die VCL nicht ThreadSafe ist. In dem Falle wäre ein Neu Design deines Programmes fällig (oder alternativ böse Hacks die Dir irgendwann auf die Füße fallen).

Mattze 14. Nov 2008 13:27

Re: Processmessages nicht anwendbar. Was nun?
 
Hallo,

vielen Dank für Eure wirklich sehr schnelle Antwort.

Ich muss gestehen, dass ich in den letzten Jahren nur ein einziges Mal Probleme mit application.processmessages hatte. Und dann war es an der Stelle sowieso nicht nötig. Also von daher finde ich es so schlimm (,wie ich natürlich auch gelesen habe,) nicht.
Ich kann mir momentan auch nicht vorstellen, wie ich es umgehen könnte.

Wenn ich auf einen "Abbruchbutton" clicke, nutze ich doch schon die GUI.
Mein Programm ist nur mein privater WindowsExplorerersatz. Macht viel mehr und gefällt mir einfach besser. (Ist ja klar!) In sofern nutzt es die GUI sowieso sehr intensiv. Das Programm kann man nicht wahrscheinlich kaum von der GUI trennen, oder sehe ich das falsch?
In diesem Programm nutze ich massenhaft Fremdkomponenten (z. B. TVirtualExplorerEasyListview). Wieweit die die GUI nutzen, weiß ich nicht. Rausnehmen geht aber garantiert auf gar keinen Fall!

Es bleibt also nur, das Processmessages irgendwie zurechtzubiegen. Aber wie?

Gruß
Mattze

Fridolin Walther 14. Nov 2008 13:58

Re: Processmessages nicht anwendbar. Was nun?
 
Nunja, möglich wäre Application.ProcessMessages im Main Thread auszuführen. Das könnte man mit AsyncCalls realisieren:
Delphi-Quellcode:
 EnterMainThread;
 try
   Application.ProcessMessages;
 finally
   LeaveMainThread;
 end;
Damit wäre sicher gestellt, das ProcessMessages definitiv im Main Thread ausgeführt wird, auch wenn die Methode grade in irgend einem anderen Thread ausgeführt werden sollte.

Apollonius 14. Nov 2008 16:03

Re: Processmessages nicht anwendbar. Was nun?
 
Was soll das bringen? Mit dem Hauptthread kann nur synchronisiert werden, wenn er gerade pausiert, also Nachrichten entgegennehmen kann. Daher ist ein Application.ProcessMessages in dieser Form absolut sinnfrei. Wenn man Application.ProcessMessages nur ausführen will, wenn man im Hauptthread ist, kann man auch MainThreadID und GetCurrentThreadId vergleichen.

Fridolin Walther 14. Nov 2008 16:05

Re: Processmessages nicht anwendbar. Was nun?
 
[EDIT]Löschen bitte ... Logikfehler.[/EDIT]


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:22 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz