Was dann in den LParam- und WParam-Parametern referenziert ist, ist der Queue vollkommen egal.
Logisch, ich bezog mich rein darauf:
Irgendwo hab ich mal was gelesen, was auf das Mitliefern von Daten hindeutete, könnte aber u.U. um andere "Messages" gegangen sein, da sehe ich noch nicht 100%ig durch (siehe 1.).
Konkret also: Wenn es die Möglichkeit gibt, der Message selbst eine Speicherreservierung im Verantwortungsbereich der Message (also keinen Zeiger auf in der Application reservierten Speicher) mitzugeben (= Daten direkt anzuhängen), dann wäre eine Begrenzung nach MB ungleich einer Begrenzung nach Anzahl. Offenbar trifft das aber nicht zu. Bei dem, was ich da mal gelesen hab, muss es um ein anderes Messaging-System gegangen sein (vielleicht dieses MSMQ).
Zusammenfassung des Beantwortungsstandes bis jetzt:- vollkommen offen
- Eine Begrenzung scheint nach Anzahl Messages zu existieren. Unklar: Wenn PostMessage aufgrund einer vollen Queue fehlschlägt, soll man es noch einmal probieren. Was muss in der Zwischenzeit geschehen, damit es beim zweiten Versuch überhaupt klappen kann? Hilft hier nur ProcessMessage(s)? Das fände ich für meinen Anwendungsfall echt blöd.
Mein Anwendungsszenario:
Ich reagiere auf Events einer Telefonanlage. Manchmal hängen mehrere davon in der Queue. Diese müssen in der korrekten Reihenfolge abgearbeitet werden. Muss ich nun in einem Event-Handler eine Messagebox anzeigen, dann würden an dieser Stelle die anderen wartenden Events abgearbeitet (das modale Fenster der Messagebox arbeitet mit ProcessMessages) und der Rest des Event-Handlers würde erst nach den anderen Events abgearbeitet. Deshalb sende ich mir eine Message und zeige die Meldung erst an, wenn ich die Message erhalten habe (also asynchron). Werde ich meine Message an der Stelle nicht los, weil die Queue voll ist, kann ich sie also auch nicht leeren, um die Message loszuwerden.
"Seit er seinen neuen Computer hat, löst er alle seine Probleme, die er vorher nicht hatte."