Hi
Um Fehler beim Senden von Daten übers Netzwerk bzw. übers Internet zu vermeiden, kann man man ja vor dem Senden von Daten Application.Processmessages aufrufen. Aber was macht dieser Befehl denn ganau? Hält er das gesamte Programm an, bis die noch zu übertragenden Daten übertragen sind? Das wäre ja ziemlich schlecht, denn wenn Daten von einem Server an viele Clients geschickt werden, dann müssten die ja alle der Reihe nach nacheinander geschickt werden.

Moderiert von Peter Lustig (12:36, 08.05.2004): Topic verschoben

Hi,

Windows ist ja ein Nachrichtenbasierendes System, das bedeutet, dass alle Aktionen durch eine Nachricht ausgelößt werden. Du musst dir das Vorstellen wie einen Breifkasten. Die Programme bringen Nachrichten und das System muss diese dann ausführen und gegebenenfalls beantworten. Wenn du nun ein sehr intensives Programm hast das andauernt neue Nachrichten bringt, können die andern Programme keine mehr bringen. Das Sytem scheint zustehen. Wenn du nun ProcessMessages ausführst "stoppst" du dieses intensive Programm so dass auch andere Programme mal eine Nachricht einmeißen können.

BungeeBug hat folgendes geschrieben:

Wenn du nun ein sehr intensives Programm hast das andauernt neue Nachrichten bringt, können die andern Programme keine mehr bringen.

Doch, bringen tun sie immer noch welche. Aber es geht keiner mehr zu deinem Briefkasten und holt sie ab.

BungeeBug hat folgendes geschrieben:

Das Sytem scheint zustehen.

Wenn nicht gerade der Thread den Status TimeCritical hat, bleibt nur die Oberfläche deiner Anwendung stehen...

BungeeBug hat folgendes geschrieben:

Wenn du nun ProcessMessages ausführst "stoppst" du dieses intensive Programm so dass auch andere Programme mal eine Nachricht einmeißen können.

...weshalb auch diese Aussage nicht stimmt, denn die anderen Programme werfen weiterhin Nachrichten rein.
ProcessMessages macht nichts weiteres als zum Briefkasten zu gehen und der Reihe nach jede Nachricht rauszuholen, bis der Briefkasten leer ist, wobei für jede Nachricht der entsprechende Handling-Code ausgeführt wird.

tommie-lie hat folgendes geschrieben:

Wenn nicht gerade der Thread den Status TimeCritical hat, bleibt nur die Oberfläche deiner Anwendung stehen...

Was meinst du mit Oberfläche der Anwendung? Ich will die Client und Server-Komponenten in einem OpenGL-Spiel verwenden. Wenn die "Oberfläche der Anwendung" stehen bleibt, bleibt dann auch mein OpenGL stehn?

ich würd sagen beides ist richtig, je nach Version.
Bis Windows <NT war alles Nachrichtenbasierend, sprich eine Anwendung konnte das gesamte System anhalten.
Ab Window >=NT gilt dieses zwar auch noch, aber NUR für die eigene Anwendung.

Eigentlich sollte ein gut gecodetes Programm niemals App.PrcMsg aufrufen müssen. Dafür gibts dann threads, wenn lange dauert und ne Sanduhr nicht grad das ist, was man dem Anwender zeigen möchte.


grez
msch

MSCH hat folgendes geschrieben:

Eigentlich sollte ein gut gecodetes Programm niemals App.PrcMsg aufrufen müssen. Dafür gibts dann threads, wenn lange dauert und ne Sanduhr nicht grad das ist, was man dem Anwender zeigen möchte.

Danke für den Tipp, ich werd mich dann mal über threads informieren.

So, hab mir jetzt ein thread-tutorial downgeloadet. Bevor ich jetzt aber mein ganzes Programm in threads unterteile hätte ich noch ein Frage: Hält ProcessMessages nur den thread an, in dem es aufgerufen wird? Der Befehl heißt ja schließlich Application.ProcessMessages und das hört sich für mich so an, als würde er für das gesamte Programm gelten
Oder gibt es für Threads andere Befehle, die noch viel viel besser sind als ProcessMessages

[r2d2] hat folgendes geschrieben:

Hält ProcessMessages nur den thread an, in dem es aufgerufen wird?

Ja.
Aber sinnvoll ist ProcessMessages nur in einem Thread, der Fensternachrichten erhält, und das ist der Hauptthread. Abgesehen davon ist es bei Threads, sofern sie gut organisiert sind, nicht mehr nötig, Application.ProcessMessages aufzurufen.

Zitat:

Oder gibt es für Threads andere Befehle, die noch viel viel besser sind als ProcessMessages

Siehe oben, es besteht keine Notwendigkeit mehr für Alternativen.

Moment..!

Threads sind eben dazu da um auf ProcessMessages verzichten zu können. Falls man es dennoch benötigt, so darf Applicatio.ProcessMessages nur vom primären Thread aufgerufen werden. Für alle anderen Threads ist diese Methode absolut tabu! Im den meisten Fällen erstellt man in einem Thread sowieso keinen weiteren Fenster die eine Abarbeitung der Message-Queue des Threads erfordern würden. Ist dies dennoch der Fall dann muss man sich seine eigene ProcessMessages-Funktion schreiben, die nicht mit dem TApplication-Objekt arbeitet..!

Also mit der Aufgabe, auf ProcessMessages zu verzichten, beschneidest du die Fähigkeiten der Threads ja ziemlich arg

Motzi hat folgendes geschrieben:

Falls man es dennoch benötigt, so darf Applicatio.ProcessMessages nur vom primären Thread aufgerufen werden. Für alle anderen Threads ist diese Methode absolut tabu!

Nicht zwingend. In Threads, die keine eigenen Fenster erzeugt haben und keine eigene Nachrichtenschleife haben, macht es eben keinen Sinn, verboten ist es nicht (man geht halt zum Briefkasten, merkt, daß keiner da ist und geht wieder an die Arbeit ).

Motzi hat folgendes geschrieben:

Im den meisten Fällen erstellt man in einem Thread sowieso keinen weiteren Fenster die eine Abarbeitung der Message-Queue des Threads erfordern würden. Ist dies dennoch der Fall dann muss man sich seine eigene ProcessMessages-Funktion schreiben, die nicht mit dem TApplication-Objekt arbeitet..!

Warum? Ich hab's zwar noch nicht ausprobiert, aber der Code von TApplication sieht mir relativ sicher aus (als Fensterhandle wird bei PeekMessage 0 angegeben, Delphi6). Sorgen mache ich mir nur über die Handler, die evtl nicht Thread-Safe sind...

tommie-lie hat folgendes geschrieben:

Also mit der Aufgabe, auf ProcessMessages zu verzichten, beschneidest du die Fähigkeiten der Threads ja ziemlich arg

Das wollte ich damit nicht aussagen, sondern eben nur, dass wenn man Threads verwendet eben kein Application.ProcessMessages mehr gebraucht werden sollte..!

Zitat:

Motzi hat folgendes geschrieben: Falls man es dennoch benötigt, so darf Applicatio.ProcessMessages nur vom primären Thread aufgerufen werden. Für alle anderen Threads ist diese Methode absolut tabu! Nicht zwingend. In Threads, die keine eigenen Fenster erzeugt haben und keine eigene Nachrichtenschleife haben, macht es eben keinen Sinn, verboten ist es nicht (man geht halt zum Briefkasten, merkt, daß keiner da ist und geht wieder an die Arbeit ).

Ok, du hast recht.. wenn der Thread keine eigene Message-Queue hat kann man Application.ProcessMessages aufrufen und es kehrt halt sofort zurück weil kein "Briefkasten" vorhanden ist.. sobald allerdings ein Briefkasten da ist und man mit Application.ProcessMessages die Message-Queue des aufrufenden Threads abarbeitet könnte es durchaus gefährlich werden..! Hier sollte man dann eben eine eigene Funktion verwenden..!

BungeeBug hat folgendes geschrieben:

Wenn du nun ProcessMessages ausführst "stoppst" du dieses intensive Programm so dass auch andere Programme mal eine Nachricht einmeißen können.

Nein, das Programm wird nicht unterbrochen. Die Programmausführung unterbricht nur seine momentane Tätigkeit und sorgt dafür, dass die Nachrichtenschlange des Fensters abgearbeitet werden kann.

Desweiteren basierte schon jedes Windows auf Nachrichten. Nur das Multitasking bzw. das Multithreading war unterschiedlich implementiert:

Luckie in seinem tollen Artikel hat folgendes geschrieben:

Anmerkung: Windows 3.1 kannte noch kein "richtiges" Multithreading. Es kannte nur das sogenannte korporative Multithreading. Das heißt ein Prozess musste von sich aus Rechenzeit abgeben und eben mit den anderen Prozessen kooperieren. Das preemptive Multitasking kam erst mit Windows 95 bzw. NT. Hier bestimmt das Betriebssystem an Hand von Prioritäten wann ein Prozess wie viel Rechenzeit zugeteilt bekommt.

Quelle: www.luckie-online.de...wsFunktioniert.shtml

@Fragesteller: Bevor du jetzt hier deine Anwendung in tausend Threads zerlegst, überleg dir vorher, ob es wirklich nötig und sinnvoll ist. Auf der einen Seite helfen Threads OProbleme lösen, auf der anderen Seite halten sie aber auch gewisse Stolperfallen bereit. Und gerade für jemanden der nicht richtig weiß, was er tut, kann das böse enden.

Ich weiß nicht, wass für ein Tutorial du dir runtergeladen hast, aber ich verweise damit noch mal auf meins: tutorials.luckie-online.de