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
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)