Programmübergreifende Komnmunikation

[berens]

Hallo!

Ich möchte meine zwei Programme miteinander kommunizieren lassen. Wie löse ich das am Sinnvollsten?

Anforderungen:
* Komponente soll mit anderer Komponente kommunzieren können (WM_Copydata geht nur mit Formularen?)
* keine Netzwerkverbindung, nur lokal
* mehrere Komponenten Anwendung1.Typ1 sollen mit jeweils einer eigenen Instanz von Anwendung2.Typ2 kommunizieren können (ich kann z.B. über Netzwerk nicht den selben Port mehrfach verwenden)

Es heißt DDE sei am aussterben und ein COM-Server? Ich weiss nicht... Müllt der nicht auf Dauer die Registry zu und ist etwas "overpowered" für diesen Zweck ( = auch zu kompliziert?)

Sofern keiner einer bessere Idee hat, muss ich wohl mein "kleines" Com+ Buch (1000 Seiten, von Andreas Kosch) mal durchlesen.

Ausserdem: ich will auf keinen Fall meine komplette Anwendung 2 als Com Server, sondern wenn, dann nur die Kommunikation der beiden Programme darüber. Wie geht das?

Für alternativ Ideen bin ich sehr dankbar :)

[Robert Marquardt]

Sockets oder Named Pipes.

[Apollonius]

Zitat:

Zitat von berens

mehrere Komponenten Anwendung1.Typ1 sollen mit jeweils einer eigenen Instanz von Anwendung2.Typ2 kommunizieren können

Wie soll denn dein Programm wissen, mit welcher Instanz es kommunizieren soll? Wenn es nur eine Instanz gibt, dann kanns du es am einfachsten über sendmessage machen (Da brauchst du nur irgendein WinControl, das die Daten empfängt - denn sonst können Programme ja nicht auf Windowsnachrichten reagieren.

[berens]

Apollonius:
Anwendung 1 startet Anwendung 2 (falls nicht erwähnt ;) ), ich kann somit Parameter über die Kommandozeile übergeben.

Robert Marquardt:
Sockets ist halt immer so eine Sache (Firewall etc; Funktionalität nicht gewährleistet)
Named Pipes hört sich laut Hilfe sehr interessant an, scheitert aber schon wieder an der praktischen Umsetzung. Hier im Forum wurde schon ein paar Mal Beispiele angefragt (kein qualifiziertes gefunden), und nPipes (die Komponente) stürzt bei mir schon als fertige .exe Demo ab, also verschwende ich meine Zeit lieber nicht auf eine Technik, die mir noch mehr Probleme macht, als ich eh schon habe :/

Ich glaube die Lösung läuft aber im Endeffekt wohl doch auf Sockets hinaus, wobei mir die von Delphi6 am liebsten wären. Mit Indy hab ich bisher net so dolle Erfahrungen...

[Apollonius]

Zum Verständnis: Ist das Ganze eine Konsolenanwendung?

[berens]

Nein, es bezieht sich auf http://www.delphipraxis.net/internal...t.php?t=108028

Ich will damit bezwecken, dass "Form1" die Position setzt, die "Form2" ihm übermittelt.

[Apollonius]

Du übergibst der neuen Instanz einen Integer (z.B. wm_user+10).
Für beide Forms musst du dich dann in die Nachrichtenschleife einklinken. Dies ist die Methode wndprocdes Forms. Also deklarierst du

Delphi-Quellcode:

TForm1=class(TForm)
 protected procedure wndproc(var Message:TMessage); override;

Un dann in der Implementation:

Delphi-Quellcode:

procedure TForm1.wndproc(var Message:TMessage);
begin
if Message.msg=meineNachricht then //<--Der übergebene Integer kommt in Meinenachricht
 begin
  //Behandle die Nachricht und Nutze dabei lparam und wparam
 end
else
 inherited; //Standardnachrichtenbehandlung
end;

[alzaimar]

Aber wenn Du doch schon Formulare hast, dann mach es doch mit WM_COPYDATA.

Ich habe z.B. ein kleines unsichtbares Fenster, das WM_COPYDATA Messages versendet und empfangen kann. Um eine 'Verbindung' zu einer anderen Anwendung aufzubauen, suche ich einfach nach anderen Fenstern mit dem Klassenname 'TMessageDispatcher'. Nun kann ich direkt mit anderen Fenstern Kontakt aufnehmen.

Früher hab ich das mit Shared Memory gemacht. Wenn es darum geht, einen Speicherbereich gemeinsam zu verwalten, dann bietet sich Shared Memory zusammen mit prozessübergreifenden Semaphoren an: So hat man ein sehr effizientes 'Notify', wenn der gemeinsam genutzte Bereich verändert wurde: Die Anwendung, die dort irgendetwas verändert, 'zuppelt' dann an der Semaphore und alle Anderen bekommen es mit.

Aber dazu musst Du auch lesen: Nämlich was über Threads und Synchronisationsobjekte. Ohne Lesen und Lernen kommste nun mal nicht weiter.

[Apollonius]

Wenn ich das jetzt mal so durchüberlege:
1. Wenn du das neue Programm startest, dann sende ihm als Parameter das Handle des eigenen Formulars
2. Das neue Programm muss jetzt (mit wm_copydata oder irgendeiner anderen Nachricht) sein eigenes Handle zurückschicken
3. Nun kennen beide Programme das Handle des anderen, also können sie sich mit wm_copydata Nachrichten schreiben.

[berens]

Das dürfte generell gehen. Weshalb ich es ursprünglich nicht mit WM_Copy machen wollte ist halt dass die einzelnen Komponenten unabhängig von dem Form, indem sie platziert sind arbeiten können müssen (also eine Komponente, NICHT das Form muss mit dem anderen Programm kommunizieren), aber dann muss ich wohl mehrere unsichtbare Forms machen oder sowas :(

Aber Danke schonmal für die Antworten!

[Apollonius]

Wessen Handle du übergibst, ist letztlich vollkommen egal. Allerdings empfielt sich meiner Meinung nach das Form, weil du ja die Nachrichtenprozeduren neu anlegen musst und somit nicht mit den VCL-Komponenten im Designmodus arbeiten kannst.

[Hansa]

Ich würde mal das gesamte Konzept des Programmes überdenken. Sieht alles ziemlich wackelig aus. Ob das so was wird ? :mrgreen: