Hmm, ein nettes Programm, und sicher auch sehr brauchbar, wenn man die Kommunikation in einem 2. Thread ablaufen lassen will. Hat aber nicht mehr viel mit dem gemeinsam, was ich im Sinn hatte: nämlich zwei möglichst einfach und flexibel zu verwendende, gegebenenfalls auch leicht erweiterbare Units (z.B. hinsichtlich anderer Datentypen) für
IPC zu schreiben. Durch die Callback Routine - die Frequenz sollte eigentlich vom Aufrufer einstellbar sein - ist man diesbezüglich wahrscheinlich eingeschränkter, jedenfalls sind Anpassungen nicht mehr so einfach zu machen. Durch die Organisation mit Thread und Callback-Funktion wird dem Benutzer der
Unit eine starrere Anwendungsstruktur aufgezwungen (oder er muss die Daten in der Callback Routine extra puffern, und wieder eigene Prozeduren zum Abholen der Daten schreiben), als wenn die Daten einfach mit GetString, oder in weiterer Folge mit GetByte, GetReal oder überhaupt GetMyRecord abgeholt werden können, wann und WIE immer es günstig erscheint - vorausgesetzt, der Puffer ist ausreichend dimensioniert.
Ich würde meinen, es wäre besser, den Thread als separate Klasse zu programmieren, der ihrerseits die ursprüngliche IPCClient Klasse verwendet, um die Daten abzuholen. Damit stünde die Threadfunktionalität zusätzlich zu den Möglichkeiten der Originalklasse zur Verfügung, die ja auch völlig asynchron verwendet werden kann.
Den Sinn einiger Deiner Änderungen habe ich nicht verstanden, z.B. wozu Du eine protected und eine public isData Funktion samt Rekursion eingeführt hast, die gemeinsam nicht mehr tun als der ursprüngliche 5-Zeiler, und wozu Du den Type Buffer in einer eigenen
Unit veröffentlichst - Ich habe ihn bewusst in den protected Bereich der beiden Klassen gelegt, weil die interne Struktur für den, der die Klassen verwendet, nicht relevant ist und ich sie deshalb eben nicht öffentlich haben wollte. Natürlich muss bei einer Änderung der Struktur in beiden Units diese Änderung parallel gemacht werden, aber nachdem bei einer solchen Änderung ohnedies auch der Programmcode in beiden Units entsprechend angepasst werden müsste, ist das ziemlich egal.
{$R-} ist die Delphi Defaulteinstellung, man sollte das vielleicht zur Sicherheit zusätzlich an den Anfang der beiden Units setzen. Nach den kritischen Stellen, wo eine Bereichsprüfung eine
Exception auslösen würde, für den ganzen weiteren Code die Bereichsprüfung - entgegen den Delphi Defaulteinstellungen - einzuschalten, halte ich nicht für eine gute Idee - obwohl es zumindest beim aktuellen Code ziemlich egal ist, weil dort, glaube ich, keine Bereichsprüfungen mehr in Frage kommen. Aber andere Units übersetzt Du ja normalerweise auch nicht mit {$R+}, oder?