Nur hätte es mit DLL's nicht funktioniert weil man da das ganze immer nur einmal laden kann ...

Ja klar. Pro Anwendung. Allerdings ist es dort auch nicht so sonderlich schwer. Und wenn ich mir die Probleme und Typenverwuchselungen so ansehe frage ich mich was da schwieriger zu lösen ist.

Das ist doch immer noch das Problem aus dem Thread "Form mehrfach aus DLL Laden", oder? Da hättest du ja nur ein halbwegs gescheite Fensterverwaltung implementieren müssen welche mit einer Basisklasse arbeitet. Und schon wäre es das gewesen.

Letztenendes issen aber relativ egal wie es gelöst ist. Die Hauptsache ist, dass es funktioniert und man es benutzen kann. In deinem speziellen Fall sollten es die anderen Programmierer aber auch noch programmieren können.

Damit die anderen damit programmieren können erstelle ich ja die Basis Klasse. Dort sind die ganzen Funktionen wie Einstellungen Laden/Speichern definiert. Diese muß halt jedes Package haben da die Hauptanwendung lediglich die Funktionen ausführt. In jedem Form eines Package werden die leeren funktionen der Basis Klasse dann einfach überschrieben und mit den Daten für das jeweilige Package gefüllt. Ansonsten steht ein normales Delphi Formular zur Verfügung was mit Inhalt gefüllt wird. Gefällt mir eigentlich bis jetzt wirklich gut. Vorallendingen bleibt man hier, ich nenn es mal, "Delphi Intern". Man geht nicht den umweg über dll's.

Eine dll Interne Fensterverwaltung wäre wesentlich auffändiger geworden. Weil dann wieder Massenweise Daten extra an die dll übertragen werden müßten und die dll dann zu sehr unabhängig von der Hauptanwendung Arbeitet.

Auch auf die Gefahr hin, dass ich mich gerade unbeliebt mache. Aber ein Package (bpl) ist vom Prinzip und Aufbau her auch nur ne DLL. Und wenn du aus einer DLL eine Klasse an deine Hauptanwendung übertragen würdest wärst du damit auch schon inkompatibel zu anderen Programmiersprachen. Und verwaltung ist da von mir ein wenig falsch ausgedrückt. Es würden eine bis maximal eine Hand voll Funtionen genügen. Aber Egal. Es funktioniert ja und das ist ja die Hauptsache.

Möglicherweise habe ich auch eine leichte Abneigung gegen Packages. Ich habe damit einfach zu viel scheiße erlebt. Also irgendwelche Leute die kompilierte Packages weitergeben haben. Das dumme daran war, dass diese Packages (so geil deren Inhalt auch sein möge) sich einfach nicht auf anderen Delphiversionen kompilieren lassen wollten. Also es genügte dort schon ein Patch was zuviel eingespielt wurde oder sonst etwas. Und schon ließ sich das Programm nicht mehr kompilieren. Und da ist eine DLL eindeutig nicht so empfindlich und man muss seine gesammten Quellen auch nicht offen legen.
Also gebranntes Kind und so.

Das problem habe ich aber nicht. Die SharpE Public Beta 4 basiert komplett auf Delphi 6. Alle Anwendungen und Plugins sind mit Delphi 6 geschrieben und die immer benötigte VCL und RTL grund Packages sind werden von SharpE selbst installiert. Die VCL und RTL Packages werden als runtime packages integriert. Dadurch benutzen wirklich alle SharpE Teile das gleiche...
Wir hatten es aber mal probiert die SharpBar mit Delphi 7 ohne runtime packages zu compilieren. Dies hatte zwar soweit funktioniert, und die SharpBar hat auch brav gestartet. Aber 50% der dll Plugins haben wenn sie denn noch funktioniert haben nicht mehr so funktioniert wie vorher...
Man bekommt also auch mit dll's , wenn man sie so nutzt, Probleme...

Verdammt... Es gibt ein neues Problem!
Wenn ich nun ein zweites Package mit der selben Struktur erstelle und versuche mit LoadPackage zu laden kommt der Fehler
"Konvertierungstyp (PackageName) ist bereits registriert".
Das ganze passiert u.a. auch wenn ich ein komplett leeres Package nehme und darin irgendeine Unit als Contain rein nehme die in dem anderen Package auf drin ist. Also wenn ich z.B. die "TColorPanel.pas" mit rein nehme weil ich die TColorPanel Komponenten benutzen will und in beiden Packages dann die "TColorPanel.pas" als Contain drin ist dann reicht das schon und nix geht mehr

Ist ja auch Logisch. Du würdest somit die TColorPanel Komponente mehrfach im Delphi registrieren und das geht nicht. Du müsstest deine TColorPanel in ein seperates Package auslagern. Das musst du im Delphi installieren und dann kannst du diese Komponente in so vielen Packages wie belieben einsetzen. Weil die sie dann nur benutzt und nicht erstellst.

Dieser Ausschluß betrifft nicht nur das Registrieren von Komponenten, sondern auch Units. Alle Packages und Exe Dateien haben eine Ressource, die angibt, welche Units enthalten sind und daher gibt es auch bei doppelten Units Fehler. Wie Lossy Ex schon meinte ist eine Lösung die gemeinsam genutze Unit in eine Extra Package auszulagern,die dann alle anderen Packages benutzen, wie das auch bei der VCL gemacht wird. z.B wird die Unit classes nur ein einziges Mal geladen. Anders ginge es ja auch nicht, weil sich dort die globale Liste mit registrierten Klassen befindet.

Müßten dann nicht auch die Units/Formulare die ich in die Hauptanwendung lade jedesmal unterschiedliche Namen haben?

Ja. Die Units dürfen nicht den gleichen Namen haben, weil das Laden der Package dann fehlschlägt. Man kann nicht 2 Klassen mit dem gleichen Namen registrieren, so daß die Form dann nicht aus der Ressource geladen werden könnte. Zwei Komponenten dürfen außerdem nicht den gleichen Namen haben, wenn sie in einer gleichen Liste auftauchen, wie das bei dem Formen bei TScreen dann der Fall wäre.