dll als Bindeglied zwischen 2 Programmen

[sirius]

Zitat von rab0r:

Hab versucht ein WM_MMFNOTIFY an die Dll zu schicken, woraushin eine Messagebox mit 'notify' kam, kein 'dispatching'....

Du musst unterscheiden zwischen sendmessage und postmessage. Bei sendmessage kommt die Nachricht direkt an das ZielFenster und nicht über die MessageQueue und demanch auch nicht über getmessage.
Und wenn du für das WM_Quit ein breakpoint bei deallocatehwnd setzt?

[rab0r]

Zitat von Apollonius:

Wie hast du es denn mit der Semaphore versucht? Habe ich das richtig verstanden, dass du eigentlich nur den Datenaustausch über eine MMF synchronisieren willst?

Genau darum gehts mir Wegen mir kann der Datenaustausch auch über ne Namedpipe laufen, nur TCP will ich nicht unbedingt bemühen..

Semaphore hab ich angelegt in meinem Programm A mit Startwert 0 und Maximalwert 1, in der Dll geöffnet und mit WaitForSingleObject gewartet. Wenn nun im Programm A nen Button gedrückt wird, mach ich ein ReleaseSemaphore und direkt ein WaitForSingleObject, das WaitFor.. in der Dll kehrt zurück, ich hole in der Dll die Daten aus Programm B (das hat die Dll geladen), mache ein ReleaseSemaphore und das Programm A weiß dass die Dll fertig ist... Den Ablauf kann man natürlich so noch länger hin und her wechseln lassen, um mehrere Daten über das MMF zu übertragen, allerdings hab ich da das Problem, dass manchmal ein Eintrag mehrmals im Programm A ankommt oder dass nicht alles ankommt.. Keine Ahnung, wieso... :/

Gibts zur Synchronisierung vllt ne schönere Möglichkeit?

LG

Edit:

Zitat von sirius:

Du musst unterscheiden zwischen sendmessage und postmessage. Bei sendmessage kommt die Nachricht direkt an das ZielFenster und nicht über die MessageQueue und demanch auch nicht über getmessage.
Und wenn du für das WM_Quit ein breakpoint bei deallocatehwnd setzt?

Habs nun auch mit PostMessage versucht, hat aber nichts geändert, nur dass das Programm das die Dll lädt nun abstürzt wenn ich WM_QUIT sende.... MessageBoxen bekomm ich immernoch nur die 'notify' und keine aus der Loop... Wie geht das mit nem Breakpoint in ner Dll, wenn die Dll von nem externen Programm geladen wird?

[Apollonius]

So aus der Beschreibung kann ich keinen Fehler erkennen... Allerdings kannst du statt einer Semaphore mit Maximalwert 1 auch ein Event nehmen.

[rab0r]

Zitat von Apollonius:

So aus der Beschreibung kann ich keinen Fehler erkennen... Allerdings kannst du statt einer Semaphore mit Maximalwert 1 auch ein Event nehmen.

Das Problem an den Semaphores ist eben auch wieder, wenn die Dll vom Programm unloaded wird, während WaitForSingleObject noch läuft (sollte es ja eigentlich immer), das Programm abstürzt, sobald WaitForSingleObject returned...
Hat vielleicht jemand ne Idee, woran das liegen kann? Erzwingt das Programm vielleicht das freigeben von Ressourcen, bevor die Dll sich selbst aufgeräumt hat?
Vielleicht sollte ich hier ansetzen um ne vernünftige Lösung zu finden.....

[shmia]

Ich hätte da noch eine Idee, wie man das mit COM machen können:
Wenn eine Anwendung gestartet wird, schaut sie in der ROT (Running Objekt Table) nach einer bestimmten CoKlasse.
Ist es vorhanden, wird der Interface-Zeiger abgeholt, falls nicht wird das Objekt neu erzeugt.

Delphi-Quellcode:

try
  connector := GetActiveOleObject('InterAppConnector.Application'); 
except 
  connector := CreateOleObject('InterAppConnector.Application'); 
end; 
  connector.AddMember('Programm XY Vers. 1.8');
  ...
  connector.Collection.AddItem('test', 47.11);

Dieses COM Objekt enthält nun eine Collection, in der beliebige Daten abgelegt werden können.
Zwei oder mehr Anwendungen haben jetzt gleichzeitig Zugriff auf die Collection und können dort lesen und schreiben.

Man könnte das noch weiter ausbauen, indem man verschiedene Collections zulässt.
Ausserdem könnte jede Anwendung eine Callback-Schnittstelle anmelden um sich über Änderungen informieren zu lassen.

Vorteile:
* Unabhängig von der Programmiersprache können so Daten zwischen verschiedenen Anwendungen (auch VB/Java-Scripts) ausgetauscht werden.
* einmal programmieren und immer wieder verwenden, da universell (unter Windows) einsetzbar
* Entladen der ActiveX-DLL wird von Windows automatisch erledigt
Nachteile:
* NamedPipes oder TCP/IP sind schneller

[Apollonius]

@@rab0r: Das Problem ist relativ einfach. Wenn die DLL entladen wird, wird der Speicher, in dem der Code stand, freigegeben. Wenn nun am Ende von WaitForSingleObject (welches in den immer noch geladenen Windows-DLLs steht) zurückgesprungen wird, ist die Rücksprungadresse somit ungültiger Speicher, also gibts ne AV.

[rab0r]

Zitat von Apollonius:

@@rab0r: Das Problem ist relativ einfach. Wenn die DLL entladen wird, wird der Speicher, in dem der Code stand, freigegeben. Wenn nun am Ende von WaitForSingleObject (welches in den immer noch geladenen Windows-DLLs steht) zurückgesprungen wird, ist die Rücksprungadresse somit ungültiger Speicher, also gibts ne AV.

Ja ok so hab ich mir das schon gedacht, ich weiß nur nicht so recht, wie ich was dagegen machen kann.. In der Dll wird eine Prozedur aufgerufen, wenn die Dll im Programm entladen wird.. Im Moment rufe ich einfach die Terminate-Funktion meines TThread-Objekts auf. Muss ich dann vieleicht noch warten, bis der Thread sich selbst aufgeräumt hat, bis ich in der Unload-Prozedur returne? Wie mach ich sowas am Besten? Soo utopisch is es ja nun auch wieder nicht, dass eine Dll einen Thread erstellt....

Zum Thema COM: Meine Vermutung ist ja immernoch, dass die Syncronisation noch nicht 100% klappt, da bringt mit das Umsteigen von MMF auf COM auch erstmal nichts...

Immernoch über Vorschläge dankbar, Groxxda

[Apollonius]

Es gibt ein paar gute Möglichkeiten, den Thread abzubrechen. Am einfachsten ist wohl, wenn du mit WaitForSingleObjectEx wartest und dann vom Hauptthread aus QueueUserAPC aufrufst, zusätzlich am besten mit WaitFor auf den Thread warten. Im Thread prüfst du den Rückgabewert von WaitForSingleObjectEx, und falls er WAIT_IO_COMPLETION ist, weißt du, dass du abbrechen musst. So kannst du ein langes Warten vermeiden.

[sirius]

Statt über APC dürfte aber auch MSGWaitForMultipleObjects gehen, welches man mit einem Event oder mit einer Thread-Message auswecken kann. (Habe ich noch nie ausprobiert)

[rab0r]

Zitat von Apollonius:

Es gibt ein paar gute Möglichkeiten, den Thread abzubrechen. Am einfachsten ist wohl, wenn du mit WaitForSingleObjectEx wartest und dann vom Hauptthread aus QueueUserAPC aufrufst, zusätzlich am besten mit WaitFor auf den Thread warten. Im Thread prüfst du den Rückgabewert von WaitForSingleObjectEx, und falls er WAIT_IO_COMPLETION ist, weißt du, dass du abbrechen musst. So kannst du ein langes Warten vermeiden.

Ich versuch das mal, auch wenn ich da noch Probleme hab, weil ich mit QueueUserAPC noch nie was gemacht hab und auch noch nicht so 100% verstanden hab, wie dus meinst....

LG