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?