DLL und Callback-Funktion: Hostprogramm reagiert nicht?

[romber]

Zitat von BUG:

Ist die Callback-Funktion thread-safe? Also: Gibt es keine Race Conditions oder Deadlocks?

Ich denke schon. In der Callback-Funktion wird lediglich ein XML-Parser (himXML, danke an himitsu) erzeugt und mit übergebenen Daten gefühlt. Dann wird ein neues einfaches Objekt erstellt, dem die Values aus den XML-Nodes zugewiesen werden. Am Ende wird das neue Objekt einer Objektliste hizugefügt, natürlich geschützt mit TCriticalSection.

Aber auch wenn ich eine ganz einfache Callback-Funktion erstelle, in der ich die Daten einfach in einem TMemo anzeigen lasse, tritt der Fehler trotzdem auf.

[romber]

Das Problem ist immer noch da

[jaenicke]

Zitat von romber:

Aber auch wenn ich eine ganz einfache Callback-Funktion erstelle, in der ich die Daten einfach in einem TMemo anzeigen lasse, tritt der Fehler trotzdem auf.

Mit Synchronize natürlich?

Hast du Fehler in deinen Threads denn auch schön ordentlich mit einem try..except außen herum abgefangen? Denn Exceptions in Threads, die nicht abgefangen werden, können sich genau so äußern. (Anderswo auch, aber in Threads ist das besonders schlecht.)

Und dann gibt es da auch noch Tools wie MadExcept oder Eurekalog, die solche Exceptions abfangen und dir mitteilen wo das Problem aufgetreten ist.

[romber]

Zitat von jaenicke:

Mit Synchronize natürlich?

Nein. Wenn ich in der DLL den Aufruf der CallBack-Funktion in eine neue Thread-Prozedur auslagere und diese mit Synchronize aufrufe, passiert nichts. Ich meine, die Prouedur wird gar nicht aufgerufen.

[jaenicke]

Ah. Du versuchst das Synchronize in der DLL. Das geht so nicht, denn da fehlt der Aufruf von CheckSynchronize. Das musst du z.B. über eine exportierte Funktion der DLL aus deinem Hauptprogramm heraus in ApplicationEvents.OnIdle aufrufen.

Da das bisher nicht aufgerufen wird, wird dein Synchronize nie abgearbeitet...

[romber]

Zitat von jaenicke:

Ah. Du versuchst das Synchronize in der DLL. Das geht so nicht, denn da fehlt der Aufruf von CheckSynchronize. Das musst du z.B. über eine exportierte Funktion der DLL aus deinem Hauptprogramm heraus in ApplicationEvents.OnIdle aufrufen.

Da das bisher nicht aufgerufen wird, wird dein Synchronize nie abgearbeitet...

Ok. bevor ich jetzt wieder etwas falsch mache: ich erstelle jetzt eine neue Funktion in der DLL mit der Zeile CheckSynchronize , exportiere diese und rufe in der Hostaufendung einmal auf. Dann kann ich aus der DLL heraus mit dem hostprogramm synchronisiert. Richtig?

[romber]

Habe ich jetzt gemacht wie oben beschrieben. Hat sich nichts geändert. Die mit Synchronize augerufene Prozedur wird nicht ausgeführt.

[Der schöne Günther]

Nochmal von vorne...

1. Client "Hauptprogramm" bindet DLL ein
2. Hauptprogramm erzählt der DLL, welche Funktion es später einmal aufrufen soll, wenn es Datenmengen abzugeben hat
3. Die DLL tut viele Dinge, darunter auch mehrere Threads öffnen
4. Mehrere der Threads aus der DLL entscheiden sich nun innerhalb einer kurzen Zeitspanne, die Datenablieferungsfunktion aufzurufen
5. 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?

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?

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.