dll als Bindeglied zwischen 2 Programmen

[rab0r]

Hallo liebe Delphi-PRAXiS-Community,
Ich hab ein Problem - und zwar möchte ich eine Dll für das Programm A schreiben mit der ich Events in dem Programm abgreife und auf diese Reagiere.. Allerdings hab ich nun noch ein Programm B mit dem ich auch auf die Funktionen in der Dll zugreifen möchte..
Zum Datenaustausch würde ich gerne MMF benutzen -
Hab schon versucht über SendMessage an die Dll zu schicken, allerdings weiß ich nicht, wie ich in der Dll die Messages abgreifen kann, ohne nen globalen Hook (SetWindowsHookEx) zu erstellen.. (Is ja nicht direkt die schönste Lösung..)

Vielleich wäre eine Möglichkeit eine art "Singleton-Instanz" der Dll zu erzeugen und sie in beiden Programmen normal als Dll zu laden, allerdings weiß ich auch nicht, wie man sowas machen könnte....

Achja: Hab auch schon versucht das über Callbacks zu realisieren, bekomm aber immer Speicherverletzungen, weil die Pointer prozessübergreifend wohl keine Gültigkeit haben. (?) Vielleicht gibts ja doch irgend ne Möglichkeit hier anzusetzen?

Wenn jemand irgendwelche Ideen hat, wäre super...

LG und schonmal danke, groxxda

[arbu man]

Eine Dll kann meines wissens nicht von zwei programmen geladen werden (nicht zum austausch von Daten).
Du wirst dir wohl was anderes Suchen müssen:
- COM-Server ö.ä. die Technologie sollte da etwas bereit stellen.
- TCP: kann auch auf 127.0.0.1 laufen
- WM_COPYDATA: einfacher Wehg um strings auszutauschen
- Commandline: Eine Anwendung kann auch während sie läuft Befehle erhalten

mfg, Björn

[rab0r]

Zitat:

Zitat von arbu man

Eine Dll kann meines wissens nicht von zwei programmen geladen werden (nicht zum austausch von Daten).
Du wirst dir wohl was anderes Suchen müssen:
- COM-Server ö.ä. die Technologie sollte da etwas bereit stellen.
- TCP: kann auch auf 127.0.0.1 laufen
- WM_COPYDATA: einfacher Wehg um strings auszutauschen
- Commandline: Eine Anwendung kann auch während sie läuft Befehle erhalten

mfg, Björn

Danke erstmal,
- das mit dem dll-Singleton war ja auch nur ne Idee, schade dass es sowas wohl wirklich nicht gibt.
- tcp: gerade das wollte ich eigentlich vermeiden, weil ich find dass das ein bisschen Overkill ist
- wm_copydata schick ich ja mit Sendmessage.. Wie bekomm ich denn die Dll dazu auf diese Message zu reagieren? Muss ja irgendwie nen Listener erstellen, allerdings will ich wie geschrieben nicht direkt nen globalen Hook erstellen...
- Commandline wäre ne Möglichkeit um von der Dll das Programm zu erreichen, andersrum gehts allerdings nicht..


Wie gesagt, mein Problem ist nicht der Datenaustausch, der geht mit MMF oder einer NamedPipe super, nur woher wissen die Dll bzw Programm B, wann es lesen / schreiben soll......?

LG erstmal

[Apollonius]

Wenn du schon benannte Kernel-Objekte verwendest, kannst du zusätzlich auch noch ein Event oder eine Semaphore verwenden, die dann signalisiert werden.

[rab0r]

Zitat:

Zitat von Apollonius

Wenn du schon benannte Kernel-Objekte verwendest, kannst du zusätzlich auch noch ein Event oder eine Semaphore verwenden, die dann signalisiert werden.

Und wie bekomm ich die Dll dazu auf das Event zu listenen?
ein Konstruk à la

Delphi-Quellcode:

procedure ....(var msg:TMessage); message ....;

gibts für Dlls ja nicht.. Müsste ich nen 2. Thread in der Dll machen und da mit GetMessage() in ner while-Schleife warten?

Und von Semaphore weiß ich noch nix.. Werd mal bissl suchen :)

Danke schonmal


Edit: Das mit GetMessage haut ja auch nicht hin, weil

Zitat:

Zitat von OH

The window must belong to the calling thread

und das is ja nicht der Fall, wenn ich von meinem Programm B das Event schicke...


Oder überseh ich was?

[sirius]

Zitat:

Zitat von rab0r

Und wie bekomm ich die Dll dazu auf das Event zu listenen?

Du brauchst das:

Delphi-Quellcode:

unit MessageThread;

interface

uses classes, windows, messages;

type TMessageThread=class(TThread)
       protected
         procedure execute;override;
       private
         FWndHandle:HWND;
         procedure wndProc(var msg:TMessage);
       public
         procedure Terminate; //neue Terminate-Methode
         property WndHandle:HWND read FwndHandle; // Handle des Fensters
end;

implementation

procedure TMessageThread.execute;
var msg:TMsg;
begin
  FwndHandle:=allocatehwnd(wndProc); //Fenster erstellen
  try
    while getmessage(msg,0,0,0) do //MessageSchleife
    begin
      translatemessage(msg);
      dispatchmessage(msg);
    end;
  finally
    deallocatehwnd(FwndHandle);   //Fenster löschen
  end;
end;
procedure TMessagethread.wndProc(var msg:TMessage);
begin
  try
    self.dispatch(msg); //Message an entspr. deklarierte Methoden verteilen
    if msg.result=0 then
      msg.result:=defwindowproc(FwndHandle,msg.Msg,msg.WParam,msg.LParam);
  except
    //do something!! messagebox(...
  end;
end;
procedure TMEssageThread.Terminate;
begin
  //da in der MessageSchelife nicht auf Terminate reagiert wird,
  //beenden wir sie gleich direkt
  Postmessage(FwndHandle,WM_Quit,0,0);
  inherited;
end;

Und kannst davon ableiten:

Delphi-Quellcode:

type Txyz=class(TMessageThread)
       procedure WMUser(var msg:TMessage); message WM_User;
       //...
     end;

procedure Txyz.WMUser(var msg:TMessage);
begin
  //...
  msg.Result:=1; //wenn Message verarbeitet
end;

Jetzt musst du den Thread nur noch erstellen und kannst in die Klasse auch noch mehr reinbauen (Felder andere Methoden...)
Wenn du das in die DLL reinpackst würde ich auch gleich das Thread erstellen und löschen mit der DLLProc-Variable erledigen.

[rab0r]

Erstmal Danke für deine Antwort und den Code, sirius.

Hab das mal versucht zu implementieren, allerdings schreint das GetMessage nie zurückzukehren.. Ich kann zwar mit Prozeduren mit message-Direktive die Events empfangen, das geht wunderbar, allerdings kehrt die Funktion nie aus der while-Schleife in der Execute-Prozedur zurück.
Eine Idee, wie ichs sonst machen kann? Anscheinend brauch ich die ganze Schleife ja nicht, also könnte ich mich auch eines

Delphi-Quellcode:

while not Terminated do ;

bedienen, das ja eigentlich nichtmal nen Inhalt braucht... Allerdings lastet der Thread dann die CPU so stark aus :spin2: was ich auch nicht so prickelnd finde..
Sleeps und WaitForSingleObject kann ich auch nicht verwenden, weil das Programm, das die Dll lädt Probleme hat, wenn die Dll unloaded wird und das Sleep / WaitForSingleObject dann erst returned.. (Da stürzt das Programm ohne Fehlermeldung ab...)

Irgendwelche Alternativen?

[sirius]

Eigentlich sollte getmessage false liefern sobald es eine Message WM_Quit erhält. (Und das hat es in meinem Test auch getan) Deswegen habe ich die Methode Terminate überschrieben um die Message loszuschicken. :gruebel:

[rab0r]

Zitat:

Zitat von sirius

Eigentlich sollte getmessage false liefern sobald es eine Message WM_Quit erhält. (Und das hat es in meinem Test auch getan) Deswegen habe ich die Methode Terminate überschrieben um die Message loszuschicken. :gruebel:

Delphi-Quellcode:

try
    while getmessage(msg,0,0,0) do //MessageSchleife
    begin
      messagebox(0, 'dispatching', '', mb_ok);
      translatemessage(msg);
      dispatchmessage(msg);
    end;
  finally
    messagebox(0, 'loop done', '', mb_ok);
    deallocatehwnd(FwndHandle);   //Fenster löschen
  end;

Delphi-Quellcode:

procedure WMUser(var msg:TMessage); message WM_MMFNOTIFY;
[..]
procedure TSyncerThread.WMUser(var msg: TMessage);
begin
  messagebox(0, 'notify', '', mb_ok);
end;

Hab versucht ein WM_MMFNOTIFY an die Dll zu schicken, woraushin eine Messagebox mit 'notify' kam, kein 'dispatching'....
Schick ich WM_QUIT, bekomm ich garkeine Rückmeldung....

Ich werd noch verrückt :/ Mit Semaphore hats zwar recht gut funktioniert, allerdings kam auch teilweise Müll an........

LG

[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?

[sirius]

Zitat:

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:

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:

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:

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:

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:

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

[rab0r]

Soo - Ich machs jetzt doch über TCP -
Habs anders nicht hinbekommen, liegt wohl unter anderem auch an dem Programm, das die Dll lädt, auf das ich also keinen Einfluss habe...

Danke trotzdem an alle, die mir geholfen haben,
Lg