Hallo zusammen,

Ich stehe momentan vor einem Problem...

Ich möchte die Möglichkeit schaffen in meinem Programm komfortabel mit mehreren Projekten gleichzeitig zu arbeiten.
Die bisherige Variante einfach mehrere Instanzen zu starten und dann ständig zu switchen ist einfach nicht mehr zeitgemäss.

Mir schwebt nur vor mehrere Prozesse (nicht Threads) zu erzeugen, zwischen denen man über Tabs hin- und herschalten kann.
Wie ich es verstanden habe verfolgt Google's Chrome wohl eine ähnliche Taktik.

Leider habe ich bisher keine Idee wie ich an dieses Problem herangehen könnte, ich wäre also dankbar für jede Art von Hinweis, ob und wenn ja wie sich sowas mit Delphi realisieren lassen könnte.

Gruß
Carsten

Crosspost bei DP

Beschreibe dein Projekt ma ein wenig besser. ggf. kann man da auch ohne allzu viel Aufwand schon was machen ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Wieso Prozesse und keine Threads?

Es handelt sich dabei um eine Konfigurations-/Entwicklungsumgebung für Industriegeräte. Hier ins Detail zu gehen würde den Rahmen sprengen und ist denke auch nicht erforderlich.

Von Bedeutung ist ein TreeView über das die verschiedenen Projektbestandteile erreicht werden. Zugehörige Fenster werden dann innerhalb eines MDIs geöffnet. Diese beiden Komponenten müssten praktisch in Tabs verfrachtet werden. Die grundlegende Menüsteuerung sollte ausserhalb bleiben und das jeweils aktive Tab steuern.

Prozesse wären mir insofern lieber, dass ein Teil der zum Projekt gehörigen Daten, sowie diverse Verifizierungsmechanismen nur in DLLs vorhanden sind. (Der Delphi-Part ist praktisch nur die GUI.) Starte ich das ganze jeweils als eigenen Prozess hängt die DLL auch jeweils an einem dran und ich muss mir zumindest um diese Baustelle keine Gedanken mehr machen.

Mit etwas "Untertreibung" und einer gehörigen Portion Optimismus müsste ich so nur die entsprechenden Prozesse erzeugen, einbinden und mich in die Eventqueue des jeweils aktiven Prozesses reinhängen um die Menü-Steuerung zu realisieren.

Ich verkneif mir das "Träum weiter" an dieser Stelle jetzt mal

Hast Du bereits einmal probiert, ob die DLL theoretisch damit zurechtkommt, mehrere Projekte gleichzeitig zu managen? Also wenn Du in einem Prozess einfach mehrere Projekte öffnest? Oder ist das in der DLL so fest verdrahtet, dass die wirklich immer nur einen Datenbestand handhaben kann?

Wäre das mit mehreren Projekten durch die DLL verwalten (sprich: Mehrere getrennte Projekte werden durch die DLL getrennt behandelt) möglich, würde sich dies anbieten.

Bei Interprozess-Steuerung wird es schnell sehr schwierig. Wobei die GUI richtig platzieren über die WinAPI mit SetWindowParent noch recht einfach gehen sollte. Da ist das sinnvoll Synchronisieren der Datenbestände zwischen den Prozessen um einiges schwieriger.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Bei Interprozess-Steuerung wird es schnell sehr schwierig. Wobei die GUI richtig platzieren über die WinAPI mit SetWindowParent noch recht einfach gehen sollte. Da ist das sinnvoll Synchronisieren der Datenbestände zwischen den Prozessen um einiges schwieriger.

An der Stelle könnte der Quelltext vom bereits genannten Chrome auch interessant sein, der als Chromium ja zur Verfügung steht. Denn jeder Tab und jedes Addon läuft in einem eigenen echten Prozess. Trotzdem bekommt man davon als Benutzer nix mit, ob man jetzt animiert einen Tab löst oder andockt usw., deshalb steckt da schon einiges dahinter.

BenBE hat folgendes geschrieben :

Hast Du bereits einmal probiert, ob die DLL theoretisch damit zurechtkommt, mehrere Projekte gleichzeitig zu managen? Also wenn Du in einem Prozess einfach mehrere Projekte öffnest? Oder ist das in der DLL so fest verdrahtet, dass die wirklich immer nur einen Datenbestand handhaben kann? Wäre das mit mehreren Projekten durch die DLL verwalten (sprich: Mehrere getrennte Projekte werden durch die DLL getrennt behandelt) möglich, würde sich dies anbieten.

Die DLL stammt noch aus dem Präkambrium. Da hat an solche Luxus-Features wie das gleichzeitige Bearbeiten mehrerer Projekte noch keiner gedacht.

Kannst Du trotzdem von der DLL mal das Interface posten? Ggf. kann man daraus etwas ableiten ...

Wenn Du auf mehrere Prozesse aufteilst, wirst Du um IPC nicht drum rum kommen. Ist zwar nicht schwer, erfordert aber einiges an Arbeit und Synchronisation. Insbesondere wirst Du dann einen Loader brauchen, der sich als Tab integrieren lässt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Es handelt sich dabei um eine alte "C"-DLL mit einigen wenigen "C++"-Einschüssen für Dinge die ich überarbeitet/ergänzt habe.
In einer Instanz mehrere Projekte verwalten zu wollen wäre in etwa gleichbedeutend damit das ganze Ding wegzuschmeissen und neu zu machen. Glaub mir, die Möglichkeit auf der Ebene mit vertretbarem Aufwand was zu machen habe ich schon geprüft und wenn es eine Alternative wäre würde ich das auch bevorzugen.
Durch mehrere Prozesse würde ich "einfach" n Instanzen der DLL erzeugen, die den für's jeweilige Projekt erforderlichen Speicher, etc. unabhängig verwalten würden. Unter'm Strich also das Gleiche wie jetzt, wo die Software mehrfach gestartet wird.

Kleines Update:

Ich habe mich gestern mal noch drangesetzt und ein Testprojekt erzeugt, das mehrere Instanzen eines einfachen Testprogramms erzeugt und diese in die TabSheets einer PageControl einsetzt. Soweit kein Problem.

Etwas anders sieht es dann bei der Menü-Steuerung aus. Es ist wohl so, dass es da keine geeignete Schnittstelle gibt in die man sich reinhängen könnte. Ich würde da (wie BenBE schon prophezeit hat) um einen umfangreichen Nachrichtenmechanismus wohl nicht herumkommen...

Was du machen kannst:
- Instantiiere dir einen MMF-Bereich, der shared zwischen allen Instanzen verwendet wird
- In diesem melden sich alle Instanzen an und tragen Menübefehle ein
- Außerdem wird dort ein Aufruf von Menüpunkten weitergeleitet

- Die Hauptanwendung baut basierend auf den Informationen in der MMF das Menü (unabhängig) von der DLL auf.
- Jeder Menüeintrag ist mehr oder weniger ein Wrapper um das Eintragen des Events in der MMF.
Zur Synchronisation bieten sich Semaphore\Mutexe an, die prozessübergreifend verwendet werden.

Wobei Du ggf. die Multi-Instanz-Fähigkeit in die DLL bekommen dürftest, wenn Du jegliche globalen Variablen in einen Record zusammenfasst (struct) und dir beim Aufruf der Funktionen diesen übergeben lässt. Ist sicherlich einmal Arbeit, aber dürfte u.U. durchaus eine Option sein.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben :

Was du machen kannst: - Instantiiere dir einen MMF-Bereich, der shared zwischen allen Instanzen verwendet wird - In diesem melden sich alle Instanzen an und tragen Menübefehle ein - Außerdem wird dort ein Aufruf von Menüpunkten weitergeleitet - Die Hauptanwendung baut basierend auf den Informationen in der MMF das Menü (unabhängig) von der DLL auf. - Jeder Menüeintrag ist mehr oder weniger ein Wrapper um das Eintragen des Events in der MMF. Zur Synchronisation bieten sich Semaphore\Mutexe an, die prozessübergreifend verwendet werden.

In diese Richtung hatte ich auch schonmal überlegt. Die Menüs dienen ja nicht nur zur Steuerung, sondern müssten Zustandsänderungen erlauben, z.B. bei Kommunikation mit den Endgeräten oder zum Ein-/Ausschalten bestimmter Punkte je nach Projekt. Zu diesem Zweck könnte ich die Zustände der betroffenen Menü-Punkte in jedem geladenen Projekt/jeder Instanz puffern und würde diese beim aktiv-werden entsprechend in die MMF schreiben und in der "Verwaltungsebene" auswerten.

Mein erster Gedanke für die Menübefehle ging zwar in Richtung SendMessage, aber da u.U zusätzliche Informationen erforderlich wären ist der Weg über Records in einer MMF eleganter.
Die Zugriffe gegeneinander zur verriegeln könnte spassig werden.

Ich werde am Wochenende mal eine Mini-Applikation basteln und probieren welcher Weg mir am erfolgversprechendstend erscheint.

Edith meint noch: Anstatt die Menü-Aufrufe ins MMF zu schreiben könnte ich doch eigentlich Methoden-Adressen(Method-Pointer) mit den Zustandsinformationen in die MMF legen. Das würde die Umkehrrichtung doch praktisch überflüssig machen...?

CarstenB hat folgendes geschrieben :

Edith meint noch: Anstatt die Menü-Aufrufe ins MMF zu schreiben könnte ich doch eigentlich Methoden-Adressen(Method-Pointer) mit den Zustandsinformationen in die MMF legen. Das würde die Umkehrrichtung doch praktisch überflüssig machen...?

Die prozesse haben aber eigene Code- und Datenbereiche. Da hilft dir ein Methodpointer nichst, weil der im anderem Prozess auf was ganz anderes zeigt.

Boldar hat folgendes geschrieben :

Die prozesse haben aber eigene Code- und Datenbereiche. Da hilft dir ein Methodpointer nichst, weil der im anderem Prozess auf was ganz anderes zeigt.

Stimmt auch wieder...

Moderiert von Narses: Zitat repariert und gekürzt.

Status Quo:

Ich habe mich entschieden einen deutlich einfacheren Weg zu gehen.

Beim Start der ersten Instanz wird ein Verwaltungsprozess (mangels Fork unter Windows) erzeugt, an dem sich alle weiteren Prozesse anmelden und der die Instanzen dann verwaltet. Die verfügbaren Tabs werden einfach in allen Instanzen angezeigt und vom "Verwalter" lediglich die Sichtbarkeit derselben geändert.

Das macht umfangreiche Umbauten praktisch überlüssig. Die Kommunikation mit dem Verwaltungsteil ist absolut trivial, beschränkt sich auf gerade mal eine handvoll Nachrichten.

Trotzdem danke für die Tips.

Gruß
Carsten