Nochmal von vorne...
- Client "Hauptprogramm" bindet DLL ein
- Hauptprogramm erzählt der DLL, welche Funktion es später einmal aufrufen soll, wenn es Datenmengen abzugeben hat
- Die DLL tut viele Dinge, darunter auch mehrere Threads öffnen
- Mehrere der Threads aus der DLL entscheiden sich nun innerhalb einer kurzen Zeitspanne, die Datenablieferungsfunktion aufzurufen
- Die Funktion soll erst einmal nichts anderes tun, als die Daten, die sie übergeben bekommt, als Text in eine Memo zu werfen
Alles richtig bis hier?
Genau so ist es. Wohlgemerkt dass es sich bei dem Hostprogramm nur um eine kleine Testanwendung handelt.
Wenn ich zumindest das
Problem verstehe, dann ist es die Tatsache, dass (der Thread aus) der
DLL mit der ganzen
VCL-Geschichte des Hauptprogramms nichts am Hut hat. Und somit beispielsweise auch erst garnichts im Kontext des Hauptthreads ausführen
kann. Richtig?
Aber die
DLL greifft doch auf die Callback-Funktion zu, die wiederum auf die TMemo zugreifft. Oder habe ich die Frage falsch verstanden?
Ich würde die Datenablieferungsfunktion so bauen, dass hier Daten einfach nur abgelegt werden. Beispielsweise in einer verketteten Liste (natürlich entsprechend geschützt, z.B. mit einem kritischen Abschnitt). In deinem Hauptprogramm würde ich z.B. jede halbe Sekunde hingehen und schauen, ob mittlerweile neue Daten vorliegen. Wenn ja, kann man die ja anzeigen.
In dem eingentlichen Client wird das auch so sein. Die Daten werden von der Callback-Funktion aufbereitet und einem s.g. Custom Date Source hinzugefügt, das wiederrum einen TObejctList als Datencontainer benutzt. Kommen neue Daten an, ruft Custom Data Source eine Funktion auf, die die neue Daten im Grid anzeigt.
Trotzdem würde ich gerne wissen, warum sich das Testprogramm aufhängt.