Formular in DLL verlagern, aufrufen und damit kommunizieren?

[a.def]

Ich verfolge seit einiger Zeit die Idee ein gewisses Formular meiner Anwendung in eine weitere Exe- oder DLL-Datei zu verlagern.
Wenn die Hauptanwendung dieses Formular braucht, wird es aufgerufen.

Dieses Formular hat zwei Threads die die GUI anpassen. Was bei einem Formular außerhalb der Hauptanwendung demnach einen großen Vorteil hat ist, dass nichts mehr synchronisiert werden muss.
Das würde dann nur noch in der zweiten Datei passieren und die Hauptanwendung kann sich ausruhen und ihre Arbeit erledigen.

Jetzt aber grundlegende Fragen dazu:

- muss es eine Exe sein oder kann es auch eine DLL sein?
- wie kommuniziert man am besten und performantesten zwischen zwei Prozessen?

TStaticLabel kann ich leider nicht verwenden, da ich HTML-kompatible Labels verwende. Meine erste Idee war per WMCopyData und dann ein komplettes Record zu schicken, welches alle Informationen enthält.

Hier ist übrigens ein schönes Beispiel mit SendMessage. Aber ist das noch aktuell?

Delphi - Interprozesskommunikation mit WM_COPYDATA - http://www.michael-puff.de

[mjustin]

Zitat von a.def:

- muss es eine Exe sein oder kann es auch eine DLL sein?
- wie kommuniziert man am besten und performantesten zwischen zwei Prozessen?

Code in einer DLL wird im selben Kontext wie die EXE Datei ausgeführt. Das Formular in einer DLL unterzubringen würde daher nichts an der Belastung des Prozesses ändern.

Als Interprozess-Kommunikationslösungen gibt es Named Pipes / Mailslots, Memory Mapped Files, Sockets, und Windows Messages. Für Sockets gibt es Indy, damit kann man sich selbst definierte Protokolle erstellen oder bestehende Protokolle (z.B. HTTP) verwenden, um Daten auszutauschen. Socketverbindungen können zwischen verschiedenen Rechnern und Plattformen hergestellt werden.

[a.def]

Ok das bedeutet also, dass eine DLL nicht in Frage kommt. Demnach muss es eine Exe-Datei sein, der ich dann von meiner Hauptanwendung aus die Daten zuschicke?

[Bernhard Geyer]

Welchen Nutzen versprichst du dir davon?
Solch eine DLL-Schnittstelle vereinfacht die Implementierung nicht.

Ich war froh als ich vor Jahren so eine Schnittstelle (nicht Delphi) entfernen konnte.

[a.def]

War ja nur ein Gedanke.
Werde es dann mit einer weiteren Exe-Datei lösen.

Was ich mir davon verspreche ist, die Hauptanwendung durch Entfernen von Synchronize (in 2 Threads, beide synchronisieren Labels auf einem Formular) deutlich zu entlasten.

[Bernhard Geyer]

Zitat von a.def:

Was ich mir davon verspreche ist, die Hauptanwendung durch Entfernen von Synchronize (in 2 Threads, beide synchronisieren Labels auf einem Formular) deutlich zu entlasten.

Ich würde eher diese Stelle überlegen was hier falsch läuft als das hier mit 2 Exe gewerkelt wird.
Ist für mich genauso ein Overkill als mit DLLs zu arbeiten.

Sollten das Label so stark "belastet" sein, dann überleg mal das Aktualisierung die nur wenige ms gültig sind für den Nutzer kenen Mehrwert darstellen.
Wie wäre es statt Synchronize z.B. mit Timer zu arbeiten um z.B. nur alle 300 ms den gerade gültigen Wert anzuzeigen.

[mjustin]

Zitat von a.def:

Ok das bedeutet also, dass eine DLL nicht in Frage kommt. Demnach muss es eine Exe-Datei sein, der ich dann von meiner Hauptanwendung aus die Daten zuschicke?

Die Hauptanwendung kann einen lokalen TCP Server (d.h. ein Server, der nur Socketverbindungen auf dem loopback Adapter 127.0.0.1 / localhost akzeptiert) starten, der auf Clients wartet. In Indy gibt es dafür bereits den TIdTCPServer, in dessen OnExecute Methode man dann Daten an den Client senden kann.

Die andere Anwendung benötigt dann nur eine TIdTCPClient Komponente, sie verbindet sich mit dem Server und wartet auf Daten.

Ich habe das in einem einfachen Beispiel hier als Artikel gepostet:

Indy 10 TIdTCPServer: Server-side message push example

Der Client verwendet dabei einen eigenen Thread, um den GUI Thread nicht zu blockieren.