Sinn von DLL-Formularen

[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