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 von s.h.a.r.k:

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.