Sinn von DLL-Formularen

[TheMiller]

Hallo,

wozu kann ich Formulare in DLLs packen? Wo ist da der Nutzen? Kann es sein, dass es vielleicht für die leichte Einbindung von Plug-Ins relativ bequem ist?

Wäre nett, wenn ihr mir mal ein paar Verwendungsbeispiele geben könntet.

Danke

[HERMES]

Da hast du ja einen möglichen sinn schon gefunden, aber es dient auch dazu anwendung zu modularisieren, beispielsweise.

[TheMiller]

In wie fern? Module sind doch Plug-Ins, oder?

[Jens Schumann]

Hallo,
wenn Du Formulare auslagern möchtest sind Packages besser geeignet.

[Igotcha]

Meine Erfahrung zu Forms in dlls ist die, dass ich auch nur einen Sinn darin sehe, sie als modale Oberflächen für Plugins zu verwenden.

Ich habe nämlich auch mal nach einer Möglichkeit gesucht, MDI-Formen auszulagern und bin dabei ganz schnell an die Grenzen von "Forms in dlls" gestoßen. Das Problem ist nämlich, dass diese dlls nicht unter dem Application-Object der Hauptanwendung laufen und es bei nicht-modalen dll-Forms dann erhebliche Probleme gibt. Z.B. kann man nicht mehr "Tabben" - verläßt man einmal die dll-Form kommt man nicht mehr per Tab auf diese zurück.

Da sind Packages die bessere Lösung.

Praktische Anwendung von dll-Forms, wie schon oben gesagt, als UI für PlugIns. Die dll erhält ein Eingangsobjekt (z.B. Grafik), bearbeitet dann das Objekt und stellt es der Hauptanwendung wieder über die Schnittstelle zur Verfügung.

Gruß Igotcha

[TheMiller]

Naja, bevor ich mich entschließe, sowas zu machen, muss ich erstmal wissen, wofür das gut ist, wie es zu handeln ist und welche anderen Möglichkeiten es gibt ;-)

[negaH]

Es gibt zwei Formen von DLL's:

1.) die normalen DLLs die somit die kompletten Sourcen der VCL jedesmal einlinken, als Plugins bekannt
2.) die Packages *.BPL und darauf aufbauen DLLs die komplett mit Packages kompiliert werden und sozusagen nur den Code + Resourcen der darin enthaltenen Forms einlinken.

Der Unterschied ist schnell erklärt an Hand eines Beispieles:

Eine Anwednung mit 30 Formularen, Druckmodulen, Datenbankzugriffen etc. pp.

als Single EXE schätzungsweise 4-8 Mb groß.
als Single EXE und jedes Foum inr eigener DLL ca. 2Mb + 30 * 1Mb jenachdem was die Forumlare so benötigen. Im WorstCase also maximal 2Mb + 30 * 4Mb = 122Mb.

Nun als Packages:

Exe ca. 40-80 Kb.
Packages für VCL, Reporte und Datenbank ca. 5-7 Mb groß.
1 Form in DLL mit Packages ca. 100Kb groß.

Macht 80Kb + 5-7Mb + 30 * 100Kb = 9-11Mb insgesamt.

Es gibt also einen klaren BreakEven ab dem sich ein packagesbasiertes modulares System in jedem Falle lohnt gegenüber einer single EXE. Nicht nur in der Größe der Binaries sondern gerade auch im Support oder Entwicklung in Teams.

Pure DLL's ohne Packages lohnen sich im Grunde niemals, das ist alles nur Getrickse und bringt immer wieder nur Ärger ein. Auch wenn jetzt einige hier einen Aufschrei des Entsetzens loslassen ;) Packages und DLL/EXE mit Packages gelinkt sind die einzigste Alternative um auch OOP konform modulübergreifend auf Klassen/globale Variablen etc. zugreifen zu können. Die "Endstelle" in diesem Konzept ist die nachladbare DLL die als alleinige Vollzugriff auf die in ihr enthaltenen Klassen und Formulare hat. Sogesehen eine zusätzliche Sichtbarkeitssufe. Alles was in Packages enthalten ist kann nun durch die EXE und diese DLLs gleichermaßen benutzt werden. Ohne Tricks etc. pp. UND es wird somit mehrfach "wiederverwendet" und nicht jedesmal eine separate Kopie in die PlugIn-DLL eingelinkt.

Gruß Hagen

[TheMiller]

Wow...danke für die Erklärung.

Die Anschlussfrage: Wie linke ich diese Packages ein? Gibts da ein Tutorial? Wäre nett, wenn mir da noch ein bissl auf die Sprünge geholfen werden kann.

Danke nochmals

[mschaefer]

Moin, moin

Da gibt es dann noch eine Argumentationsschiene:
aus dem DP ThreadForms in einer DLL erzeugen

Zitat:

Zitat von MarcoWarm

also das ist alles Möglich...
Es ist so, daß es generell nicht empfohlen wird VCL-Formulare in DLLs auszulagern, da das viel Speicher fressen soll, weil die VCL mehrfach geladen werden muss. Ich mach es trotzdem und die Programme laufen auch Anstandslos. Der offizielle Weg ist, bpl's zu benutzen. Das hab ich auch schon versucht, aber da ärgert man sich nur rum und muss dem Endkunden auch die ganzen System-BPLs von Borland mitliefern (nich so schön)

Wahrscheinlich wird man nicht alle Borland bpl´s brauchen, und man muss selbst herraussuchen welche man benötigt. Leider kann man die bpl´s nicht einfach in Unterverzeichnisse zur Exe legen (bisher ist mir kein Weg bekannt), so dass ein Anwendungsverzeichnis immer gut befüllt ist. Bei dll´s ist es möglich über das explizite Laden natürlich auch bestimmen wo diese abgelegt sind, sodaß man sein system besser strukturieren kann.

Grüße // Martin

[dfried]

Zitat:

Zitat von mschaefer

Leider kann man die bpl´s nicht einfach in Unterverzeichnisse zur Exe legen (bisher ist mir kein Weg bekannt), so dass ein Anwendungsverzeichnis immer gut befüllt ist. Bei dll´s ist es möglich über das explizite Laden natürlich auch bestimmen wo diese abgelegt sind, sodaß man sein system besser strukturieren kann.

Mit den Borland BPLs kann man das nicht machen, die eigenen BPLs kann man aber sehr wohl auch in Unterverzeichnisse legen und auch nur bei Bedarf laden/entladen.

[mschaefer]

Wie !!! // Martin

[dfried]

Schau dir dazu mal die Funktionen LoadPackage und UnloadPackage an. Mit denen geht das. Hab leider grad meinen Notebook nicht griffbereit, sonst würd ich dir ein bisschen Sourcecode schicken wie ich das gemacht hab.

Daniel

[alcaeus]

Moin Martin,

LoadPackage() akzeptiert einen gesamten Pfad:

Delphi-Quellcode:

SomeHandle := LoadPackage(IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName))+'Modules\ModuleCore.bpl');

Greetz
alcaeus

[mschaefer]

Ja - Klasse !

Sorry, Loadpackage war mir bisher kein Begriff. Prima das macht das natürlich einfach. Tja wieder was gelernt :-)!


Woran scheitert das dann, dass man die Borlandpackages nicht in, sagen wir, in ein Unterverzeichnis legen kann. Könnte ich jetzt nicht im Projektquelltext die benötigten Borland bpl´s von Hand aus meinen bpl-Verzeichnis laden lassen. Dann hätte der Endanwender nur noch die Exe´s im Programmverzeichnis...?

[alcaeus]

Ich hab jetzt kein Delphi hier, also kann ich auch nicht nachsehn, ob man diesen Pfad umbiegen kann. Ich weiss nur, dass versucht wird, die Packages entweder aus dem System-Verzeichnis (C:\Windows\System32) oder dem Anwendungsverzeichnis zu laden. Vielleicht kannst du das ja erweitern, indem du den Pfad zu den Packages in die PATH-Variable eintraegst, das duerfte helfen.

Greetz
alcaeus

[negaH]

Zitat:

Dann hätte der Endanwender nur noch die Exe´s im Programmverzeichnis...?

Dann packe die EXE zu den Packages ins Unterverzeichnis und lege im Hauptverzeichnis einfach einen Link auf die EXE.

Desweiteren gibt es in der Windows Registry die Möglichkeit zu einer EXE einen eigenen Suchpfad anzulegen. Empfehlen tue ich diese Vorgehensweise aber nicht.

Normalerweise wird man bei Profi-Anwendungen, bei denen sich Packages auch lohnen, sowieso einen Link auf'm Desktop legen.

Gruß hagen

[mschaefer]

Hallo Andres, Daniel, und Hagen
zunächst mal vielen Dank!

Im Moment geht es zwar nicht, aber ich werde das demnächst mal durchprobieren. Das hat ganz praktische Folgen. Wenn per Internet aktualisert wird (oft immernoch ISDN) dann ist die Ladezeit ein Argument, wenn nach dem Laden und Übertragen noch Änderungen per Fernwartung erfolgen. Bei kleineren Datenbankupdates lohnt es sich nicht jedesmal ein Setupskript zu erstellen und hier passt das Packagekonzept sehr gut. Wenn man das noch übersichtlich in die Verzeichnisse bekommt, dann ist das auch für den Endanwender hilfreich.

PS: Die Idee mit dem Link hat hat Raffinesse, fordert aber dann einn absoluten Pfad im Link. Muß kein Nachteil sein, nimmt aber die Verschiebbarkeit. Das bringt dazu, dass es so möglich ist ein Hauptmenueprogramm ins Anwendungsverzeichnis zu legen und die Teilprogramme zu den bpl´s . Das wäre zu Überlegen....

Viele Grüsse aus dem sonnigen Hannover // Martin

[negaH]

MDI's lassen sich auch aus normalen DLL's heraus laden. Bei Formularenin normalen DLL's hat es sich bewährt in der EXE bei Laden eines solchen nicht-modalen Forms einen TForm Container zu benutzen. Das heist: die EXE erzeugt erstmal ein eigenes MDI TForm als Container und übergibt dies als Parent der DLL. Die DLL erzeugt ihrerseits ihr Formular und bindet es in dieses MDI Form als ParentWindow ein. Natürlich muß diese DLL TFormohne Caption, Border und alClient etc.pp. erzeugt werden. In diesem Moment hat man fast keinerlei Probleme mehr, bis auf den Punkt der Fokusierung der Controls auf solchen Forms.

Das Problem entsteht dadurch das die Operatoren is und as nicht mher funktionieren, das heist durch die mehrfache Einbindung der gleichen Klassen in verschiedene Module unterscheiden sich die Codesegment Zeiger auf diese Klassen, jenachdem welches Modul ein Objekt erzeugt hat. Die Abfrage und der Vergleiche einer Klasse funktioniert aber über deren Zeiger in das Codesegement in dem die Klassenstruktur, sprich RTTI, VMT und DMT etc.pp., gespeichert sind.

Diese Nachteile gibt es bei Packages eben nicht das selbst diese Codesegementzeiger duch den Compiler/Linker als DLL Funktionen exportiert werden.

Gruß Hagen

[negaH]

Wir machen es seit Jahren so:

EXE + BPLs + INIs in ein gemeinsammes Hauptverzeichnis.
Es gibt eine Schnittstellen-BPL zb. Main.bpl in der die komplette Modulverwaltung samt Hauptformular implementiert wurde.

Ladbare Module, sprich Formulare und Druckformulare, greifen nun nur auf Packages zu, inklusive Main.bpl. Sie werden in einem relativen Unterordner gespeichert zb. \Module\, und haben die Endung .MDL.

Danaben gibt es einen \Daten\ Ordner in deseen Subordnern die Daten zu den verschiedenen Mandanten stehen. In jedem Mandanten Ordner finden sich auch die Konfigurationsdateien der ladbaren Module, Menusysteme usw.

Wichtig! die Benutzung von Packages benötigt ein strafes Regime bei der Organisation der Firmenstandards der Programmierung. Man sollte und muß sich auch auf die Benutzung spezifscher Packages beschränken. D.h. einfach mal irgendwelche 3'rd party Packages einbinden wegen einer pobeligen Komponente ist nicht mehr, da es den Aufwand des Supports erhöht. Man hat so zwar einige Einschränkungen diese führen aber dazu das man die Programmierung in Teams und die eigenen Firmenstandards stärkt.

Gruß Hagen

[dfried]

Zitat:

Zitat von negaH

MDI's lassen sich auch aus normalen DLL's heraus laden. Bei Formularenin normalen DLL's hat es sich bewährt in der EXE bei Laden eines solchen nicht-modalen Forms einen TForm Container zu benutzen. Das heist: die EXE erzeugt erstmal ein eigenes MDI TForm als Container und übergibt dies als Parent der DLL. Die DLL erzeugt ihrerseits ihr Formular und bindet es in dieses MDI Form als ParentWindow ein. Natürlich muß diese DLL TFormohne Caption, Border und alClient etc.pp. erzeugt werden. In diesem Moment hat man fast keinerlei Probleme mehr, bis auf den Punkt der Fokusierung der Controls auf solchen Forms.

...

Funktioniert denn damit dann cuh noch die Tab-Taste? Ich habe auch ziemlich lange damit verbracht MDIs ind DLLs zu packen, hat auch alles soweit funktioniert, bis auf die Tab-Taste...

Daniel

[alcaeus]

Moin Martin,

ich wuerde aber davon abraten, die Borland-BPLs ins Programmverzeichnis zu kopieren. Wenn du 2 Anwendungen hast, die die Borland-Packages zur Laufzeit einbinden, dann muessen die Packages in beiden Anwendungsverzeichnissen vorhanden sein (ausser der Trick mit der PATH-Variable funktioniert), und der Vorteil der Platzersparnis ist erstmal weg.

Greetz
alcaeus

[mschaefer]

Hallo Andres,

die Begründung macht Sinn. Ist im Moment auch kein aktuelles Problem (dafür stehen heute noch einige Hashlisten auf demn Programm). Was ich bei Gelegenheit doch noch mal ausprobieren werde ist, ob ich die Borland-Packages per Fußweg im Projektquelltext aus einem anderen Verzeichnis laden kann, bevor die Formulare erstellt werden. Die Frage die dahinter steht ist: Wann wird die VCL geladen, bei Erstellen von TApplication oder bei dem Aufbau der Forms. Naja mal sehen vielleicht bekommt man das auch mit einem dll-Sniffer heraus. Man braucht dann wohl nur eine Application ohne Forms...

Grüße in den Süden

// Martin






PS: 20 Grad / Sonne / blauer Himmel / Überstunden :-(

[negaH]

Zitat:

Wann wird die VCL geladen, bei Erstellen von TApplication oder bei dem Aufbau der Forms.

Das hängt davon ab wie die Abhängigkeiten sind.

Normalerweise werden die Grundlagen Packages wie VCL,DB etc. statisch in die EXE gelinkt. Sie werden damit also beim Laden der EXE ebenfalls geladen.

Hat man nun weitere Packages die zb. nur anwendungspezifisch sind, und auf spezielle Formulare aus Modulen bezogen benötigt werden, dann werden diese Packages immer dann geladen und entladen wenn ein solchen Formular Modul geleden und entladen wird.

Diesen Fakt nutzen wir in unserem Modulsystem aus. Wir erzeugen Formulare erst bei Bedarf, sprich Nutzeraufruf, und laden dann das dazugehörige Modul ebenfalls dynamisch. Sollte dieses Formular aber auf ein eigenes mehrfach benutztes Packages statisch zugreifen, so wird dieses Packages ebenfalls dynamisch geladen. Logisch, wenn du mal tiefer darüber nachdenkst.

Einige Packages, besonders 3'rd Party Packages wie ReportBuilder, sollten aber schon statisch mit der EXE geladen werden und dann permanent im Speicher verbleiben. Denn diese Packages wurden nicht korrekt auf ein dynamsiches Entladen hin programmiert. Sie installieren Hooks oder allozieren Objekte etc. pp. und deinstallieren sie aber nicht mehr korrekt beim Entladen der Packages. Das kann dann zu Fehlern beim dynamischen Entladen führen.

Gruß Hagen

[negaH]

Zitat:

ich wuerde aber davon abraten, die Borland-BPLs ins Programmverzeichnis zu kopieren. Wenn du 2 Anwendungen hast, die die Borland-Packages zur Laufzeit einbinden, dann muessen die Packages in beiden Anwendungsverzeichnissen vorhanden sein

Bei heutigen Festplattengrößen und automatischen Setups halte ich diesen Vorschlag für nicht Support freundlich. Ich würde also genau das Gegenteil vorschlagen da so gewährleistet ist das andere Anweendungen einem nicht die Basis durch andere Packages unter dem Hintern wegreisen können. Zb. liefert Borland gepatchte Packages aus, je nach Compiler Version, die dann wenn man eine ungepatchte Delphi Version benutzt, zu massiven Problemen führen können falls diese Packages im SYSTEM liegen.

Besser also alles zur Anwendung zu speichern was möglich ist und nicht auf Speicherplatz zu schauen. Das oberste Prinzip bei kleinen Softwarefirmen heist "es muß stabil laufen". Reduziert man also unnnötige Abhängigkeiten zu Treibern, DLL's so reduziert man Probleme.

In diesem Punkt haben Linux/Unix Systeme ihren klaren Vorteil. Was sind schon 5-15 Mb Platz heutzutage ?

Gruß Hagen