Information dynamisch aus DLL (about-box)

[myicq]

Ich wurde vom Kunden gefragt : kann ich eigene Kontaktdetails in About-Box haben ?

Das ist natürlich mit sonder-Version möglich, wo ich vor dem Compile die Versionen ändere.

Aber.. mit über 200 Kunden die das potentielle auch mögen relativ umfangreich.

Kann ich diese Information (logo, 2-5 Zeilen) aus eine DLL holen, so das ich einfach eine DLL am Kunden sende, und damit
die information sich automatisch ändere (muss nicht unbedingt DLL sein, aber nur nicht einfach Logo + textdatei).

[Ghostwalker]

Jap, das geht.

Such mal nach dem Stichwort "Resource-dll" :) Da solltest du einiges dazu finden.

[himitsu]

Erstmal kann man natürlich auch sowas wie eine TXE, INI, XML oder Sonstwas verwenden.
Oder es in der Registry speichern.

Dann natürlich eine DLL mit einer/mehreren Funktion, welche dir diese Daten liefern.
* dynamisch geladen, falls sie beim Kunden existiert
* oder bei allen Kunden soeine DLL und bei diesem Kunden dann eine angepasste DLL

Und es geht auch über DLL-Resourcen (z.B. TResourceStream)
Dafü gibt es auch LoadLibraryEx + LOAD_LIBRARY_AS_DATAFILE, wenn diese DLL sonst keine weiteren Funktionen beinhaltet.


Da das Logo so oder so in die Ressourcen rein muß, wäre es fast egal, ob man diese Ressource innerhalb oder außerhalb der DLL ausließt, aber bezüglich RTTI/Speichermanagement und da man standardmäßig keine Klassen ala TBitmap/TIcon über DLL-Grenzen durchreichen darf, würde es sich von außerhalb besser gestalten.

[myicq]

OK, werde ich alles untersuchen.

Ich habe leider nur D6, und deshalb keine RTTI.

[himitsu]

RTTI hast du auch (TypInfo.pas)
Die "erweiterte" RTTI wurde später hinzugefügt.

Aber nicht du sollst die RTTI nutzen, sondern Klassen nutzen sie zur Speicherverwaltung. DLL und EXE haben je ihre eigene RTTI (wenn man nicht mit Laufzeitpackages kompiliert), was schnell schief gehen kann.
TObject der DLL ist ein "Anderes", als das der EXE. Mit Runtime-Packages liegt die "gemeinsame" RTTI der Klasse dann in den gemeinsam genutzten Packages (TObject liegt da in der RTLxxx.bpl)
Wenn in der EXE oder DLL die Codeoptimierung z.B. unbenutzte Felder/Methoden entfernt, dann stimmen die Speichergrößen/-positionen nicht überein und es knallt schnell mal.

Darum geben keine Objekte mit DLLs sharen.
Und bei Strings oder dynamischen Array muß man auch erst einen Shared-Memory-Manager einbinden, da DLL und EXE sonst jetzt ihren eigenen Speichermanager besitzen und es knallt, wenn der falsche Manager dann den fremden Speicher versucht zu verwalten.

[Ghostwalker]

Kleines Demo anbei :)

Hab das ganze zwar unter Tokyo gebaut, sollte aber auch unter älteren Versionen funktionieren.