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:

Zitat von a.def (Beitrag 1360044)

- 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.

[mjustin]

Zitat:

Zitat von a.def (Beitrag 1360053)

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.

[Bernhard Geyer]

Zitat:

Zitat von a.def (Beitrag 1360067)

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.

[a.def]

Blockieren tue ich ja nichts. Die Belastung für die Labels hält sich auch in Grenzen. In meinen Threads ist ein Sleep von 25ms. Aktualisiert werden die Labels auch eh nur dann, wenn es neue Nachrichten gibt (PeekMessage). Also ist das mit 2 Exen totaler Unfug?

[stahli]

Wenn tatsächlich nichts blockiert, warum willst Du es dann umstellen?

Wenn Du 2 Exen hast und diese nicht blockierend kommunizieren können sie sich gegenseitig auch nicht blockieren. Die Kommunikation ist aber ggf. aufwendig und etwas langsamer (Netzwerk).

Einfacher ist es, aufwendigere Berechnungen einfach in Threads auszulagern und diese für Zwischenstände oder Endergebnisse mit dem Mainthread zu synchronisieren.

Letztlich kommt es darauf wann, was Du genau erreichen willst und wo es aktuell klemmt.

[a.def]

Naja, Entlastung, weniger Code in der Hauptanwendung, bessere Update-Möglichkeiten..