Grund herausfinden, warum PostMessage() nicht funktioniert hat

[s.h.a.r.k]

Vorab: von himitsu wurde ich darauf hingewiesen, dass ich doch aufpassen sollte, wenn ich Objektreferenzen via PostMessage() hin und her schicke, da die Nachricht ja nicht ankommen muss. Ich habe es so konzipiert, dass wenn die Nachricht erfolgreich angekomme ist, der gegenüber sich auch um die Freigabe des Objekts kümmern muss. Wenn PostMessager() False liefert gebe ich das Objekt einfach blind im Sender frei.

An dieser Stelle will ich das Ganze etwas besser Differenzieren können. Ich kenne zwei Gründe, warum PostMessage() fehl schlagen kann:

• Message-Queue des Empfängers ist voll.
• Handle des Gegenübers existiert nicht.

Interessant für mich wäre nun, wie ich denn zwischen diesen beiden Gründen unterscheiden kann, um entsprechend darauf reagieren zu können.

Wenn es noch mehr Gründe geben sollte, dann wäre es zum einen interessant zu erfahren welche und zum anderen wie ich darauf eingehen kann :)

[Luckie]

Du schickst Objektreferenzen, also Pointer, zwischen Fenstern des selben Prozesses hin und her?

Wäre es nicht sinnvoller mit Ereignissen zu arbeiten?

Ob du ein gültiges Handle hast, kannst du mit der Funktion IsHandle prüfen.

[Bernhard Geyer]

Zitat:

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

Ich kenne zwei Gründe, warum PostMessage() fehl schlagen kann:

Der dritte Grund ist schlecht/fehlerhaft Programmierte SW wie NView. Mit diesen hatten wir schon öfters probleme das einfach User-Messages die im Programm gesendet wurden einfach verschluckt wurden. Vor allem bei WM_COPYDATA pfuschen Hilfsprogramme die sich in jeden Prozess hängen dazwischen.

[himitsu]

PostMessage

z.B.

Zitat:

Return Value

Type: BOOL

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks

When a message is blocked by UIPI the last error, retrieved with GetLastError, is set to 5 (access denied).

Wenn False, dann mit GetLastError den Grund auslesen.

[s.h.a.r.k]

@himitsu: Das kenne ich schon, nur habe ich mir dann auch mal die Fehlerliste angesehen und die ist ja quasi unendlich lang. Was genau für Fehler PostMessage generiert habe ich bisher nicht gefunden. Und entsprechende Situationen simulieren kann ich nicht, da ich nicht weiß, welche Fehler es überhaupt geben kann.

@Luckie: Ja, das mache ich bisher so, da diese Log-Klasse erst dann alles abarbeiten soll, wenn gerade Zeit für die Nachrichten ist. Ich denke, dass so das Programm etwas weniger "blockiert" wird. Will und werde die Log-Klasse aber bald auf eine TThread-Klasse basieren lassen. Habe da aber noch ein paar Probleme mit dem Konzept.

[himitsu]

Wozu mußt du denn ganau wissen, was es für Fehlercodes gibt?

Falls man einige Fehler geziehlt behandeln will, dann kann man die paar Codes auch ausprobieren und sonst ist es nicht wichtig genaue Fehlercodes zu kennen.

Für die Anzeige GetLastError + SysErrorMessage oder RaiseLastOSError

[s.h.a.r.k]

Existiert ein Handle, ist aber z.B. die Warteschlage der Messages voll, dann brauche ich das Handle nicht aus meiner Log-Instanz entfernen und versuche weiter Nachrichten da hin zu schicken. Existiert das Handle aber gar nicht, dann kann ich es getrost entfernen. Aber vielleicht ist ja SendMessageTimeout() ja was für mich. Muss mir das mal genauer anschauen.

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

[Luckie]

Die Funktion habe ich auch nirgends gefunden habe hier wird sie verwendet: http://stackoverflow.com/questions/5...ab-in-parallel

[himitsu]

SendMessageTimeout ... ich dachte du wolltest nichtblockierend arbeiten?

[Blup]

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.

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