Grund herausfinden, warum PostMessage() nicht funktioniert hat

[himitsu]

Zitat:

Zitat von Blup (Beitrag 1086938)

Die Objekte einfach auf einen Stapel legen und den Empfänger per Postmessage informieren, das er dieses abholen soll. Selbst wenn die Nachricht nicht ankommt, kann der Empfänger das Objekt bei der nächsten Nachricht immer noch abholen.

Gut, im Prinzip macht er sowas ja auch schon, per PostMessage ... was auch meistens funktionieren sollte.

[s.h.a.r.k]

Zitat:

Zitat von himitsu (Beitrag 1086933)

SendMessageTimeout ... ich dachte du wolltest nichtblockierend arbeiten?

Jup, will ich auch! Bin auf die Methode gestoßen und denke, dass diese ganze passend für mich wäre, da ich ja teilweise herausfinden will, ob ein Handle noch existiert, oder eben nicht. Und so kann ich zumindest feststellen, ob geantwortet wird.

Wie schon erwähnt, es ist alles nicht so ganz einfach mit diesen Nachrichten, in so fern mal eine Nachricht nicht ankommt. Ich will nach Möglichkeit auch Fehler nach "außen" geben können, sodass man z.B. in der GUI anzeigen kann, dass eine Meldung nicht geloggt wurde, oder das ein Modul nicht mehr zur Verfügung steht. Aber genau diese Analyse fehlt mir noch ganz. Ich will halt auch nicht einfach Meldungen wegwerfen und gar nicht loggen, das wäre nicht gerade transparent.

Vielleicht muss ich auch an meinem Konzept noch einiges ändern, oder auf ein ganz anderes setzen. Sollte anfangs ja nur eine simple Log-Klasse werden, die jetzt schon einen ziemlichen Umfang erreicht hat ;)

[himitsu]

Im Grunde gibt es nur 3 Fehler, welche dich erstmal interessieren

> Handle ist ungültig (Fenster weg)
> Queue ist voll
> kein Zugriff

Letzteres sollte wohl Fehlercode 5 sein, so wie es im MSDN beim PostMessage erwähnt wurde,
die anderen Beiden lassen sich leicht Testen
und den Rest kann man pauschal behandeln.
SysErrorMessage wandelt alles in Lesbares Zeugs um.

[s.h.a.r.k]

Wie kann ich prüfen ob ein Handle ungültig ist? Ein PostMessage() auf ein nicht vorhandenes Handle angewendet wird liefert es False und GetLastError den Code 5 (Zugriff verweigert). Und wie teste ich, ob die Queue voll ist?

[Dezipaitor]

Echte Handles kannst du mit DuplicateHandle kopieren und so feststellen, ob es zu diesem Zeitpunkt korrekt war. Vorteil davon ist, dass man nun eine Referenz auf das Objekt als Handle hat, welche auf jeden Fall gültig ist.

Wenn die Ziel-(nicht Quell)Warteschlage voll ist, solltest du dein Kommunikationskonzept überdenken. MSDN schreibt zu PostMessage:

Zitat:

There is a limit of 10,000 posted messages per message queue. [...] If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources.

Z.B. Könnte man ganze Datenstapel mit einer Nachricht verschicken, statt immer nur ein Datenpaket. Oder man nutzt asynchrone Kommunikation, indem man in bestimmten Zeitintervallen eine gemeinsame Ressource beschreibt und liest. Das benötigt garkeine Nachricht.

[s.h.a.r.k]

Die Grenzen für die Anzahl der Messages kenne ich schon. Wobei ich mir leicht vorstellen kann, dass diese mal voll läuft, wenn ein Programmierer z.B. eine Berechnung über mehrere Sekunden laufen lässt (ohne Threads) und in jedem Schleifendruchgang mind. eine Log-Meldung erzeugt. So können schnell 10000 Meldungen zusammen kommen, ohne dass diese Abgearbeitet werden. Ein Application.ProcessMessages könnte das beheben, macht meine Log-Klasse dann aber wieder langsamer UND ich könnte dann eigentlich gleich mit Events arbeiten.

Bisher ist das Konzept so ausgelegt, dass jede Log-Message ein PostMessage() verursucht, um die einzelnen Log-Module (Datei-Modul und Log-ListBox gibts hier im Moment) zu benachrichtigen. Jedem Log-Modul wird ein Log-Message-Objekt erzeugt und die Referenz darauf wird via PostMessage verschickt.

Ich habe im Moment folgende Idee im Kopf: um dem "Überlauf-Problem" von vorn herein aus dem Weg zu gehen, baue ich die Benachrichtigung so um, dass das PostMessage dem Modul nur signalisiert, dass neue Nachrichten vorhanden sind, enthält somit keinerlei Referenz auf die neue Log-Nachricht. Dann schaut das Modul in eine entsprechende Liste und holt sich alle neuen Log-Nachrichten selbst ab. Ist die Message-Queue voll, so kommt die Benachrichtigung zwar nicht an, aber evtl. gelingt dies dann später. Es gibt noch ein paar Haken dabei, aber vielleicht klappt das ja besser, mal sehen.

Insgesamt glaube ich, dass meine Fragen nun aber ausreichend beantwortet wurden und das Konzept-Problem hier nicht mehr so ganz her gehört. Danke schon mal an alle :)

[Assarbad]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1086864)

@Luckie: IsHandle finde ich nirgends! Wo soll es das geben?

IsWindow

[himitsu]

PS: Du kannst deine Log-Klasse, bzw. die "Form" zu dieser Klasse in einem eigenem Thread erstellen, über die nun unabhängige MessageLoop/Verarbeitungsschleife kannst du da in Ruhe arbeiten.

Wobei man nichmal eine "Form" benötigt (und man hierbei sowieso keine VCL-Form verwenden dürfte), da man Messages auch direkt an einen Thread senden kann > PostThreadMessage.