Externe Resource zur Laufzeit verwenden

[messinger]

Hallo Leute,

ich würde gern Inhalte einer Resourcen-Datei verwenden, um bspw. die Glyphs oder Captions von Buttons zu ändern. Die Resourcen-Datei habe ich. Die soll aber nicht mit in die exe compiliert werden, sondern neben der exe weiter gegeben (und ggf. vom Nutzer angepasst) werden könnnen. Die Inhalte möchte ich mir dann erst zur Laufzeit holen (um bspw. einen dynamisch erzeugten Button entsprechend anzupassen).
Solange ich die Resource in die exe mit rein compiliere, ist das Ganze unproblematisch. Ich finde nur irgendwie nichts, um die externe Resource "zu laden".
Auf keinen Fall möchte ich die ganzen Bilder als einzelne Dateien mitgeben. Gestolpert bin ich schon über den Hinweis, es mit einer dll zu versuchen, eine direkte Verwendung einer res oder rc wäre mir aber deutlich lieber.

Wäre für Vorschläge dankbar.

[himitsu]

Kompilier Linke die Ressource in eine DLL und schon kannst du alles Bekannte nutzen, womit man Resourcen auslesen kann.

[Luckie]

Und Ressourcen bekommt man genauso in eine DLL wie in eine Exe.

[messinger]

Vielen Dank - schaue ich mir mal an.

Gibt's aber auch ne Möglichkeit, direkt mit den res- oder rc-Files zu arbeiten?

[CCRDude]

Klar - z.B. per ResourceUtils. Nur ist das um Längen umständlicher als ein LoadLibrary und ein TResourceStream.

[himitsu]

Ansonsten:
Wenn du keine (richtigen) Resourcen verwenden willst, dann nimm was Anderes. (zip, xml oder sonstewas)

[neo4a]

Zitat:

Zitat von himitsu (Beitrag 1156575)

Ansonsten:
Wenn du keine (richtigen) Resourcen verwenden willst, dann nimm was Anderes. (zip, xml oder sonstewas)

Oder: Nimm etwas anderes und binde es als richtige Resource ein.

Wenn Du in Deinem Programm z.B. mehrere ClientDataSets oder MemTables verwendest und dazu noch ein paar TMemIni's, dann speichere ein Set davon mittels SaveToStream in ein Zip-File (was noch nicht einmal so heißen muss). Abbrevia ist aktuell, Open Source und unterstützt Delphi bis XE2 (auch 64bit). Diese Zip-Datei kannst Du auch mit einem beliebigen Programm weiter bearbeiten und/oder auch mit einem Passwort schützen, wenn genau das nicht durch Fremde passieren soll. Die Zip-Vorlage bindest Du als Resource mit in das Programm ein, das es dann bei Bedarf als Initialisierung am Zielsystem auspackt. Mit diesem Archiv kannst Du nur lesend, aber auch schreibend arbeiten und so z.B. ein compressed, encrypted Single-File-Database-System zum Nulltarif bauen (mit TkbMemTable 7 auch mit SQL-Syntax). Ohne zusätzliche DLL. Kein bischen.

Also ich wäre davon nun überzeugt ;)

[ASM]

Zitat:

Zitat von neo4a (Beitrag 1156591)

Wenn Du in Deinem Programm z.B. mehrere ClientDataSets oder MemTables verwendest und dazu noch ein paar TMemIni's, dann speichere ein Set davon mittels SaveToStream in ein Zip-File (was noch nicht einmal so heißen muss). Ohne zusätzliche DLL. Kein bischen.

Also ich wäre davon nun überzeugt ;)

Also ich ganz und gar nicht. Denn das geht ja ganz offensichtlich an dem vorbei, was hier erfragt worden ist, und ist außerdem einfach nur sehr unprofessionell.
1) Er hat doch deutlich geschrieben, dass er einfach nur Glyphs und/oder Captions von Buttons als Resourcen speichern will (und selbst im Falle komplexerer Resourcen wäre das nach der unten folgenden Lösung kein Problem).
2) Zitat: "Die Zip-Vorlage bindest Du als Resource mit in das Programm ein"
Vor allem aber hat er doch unmissverständlich erklärt, dass er die Resourcen eben gerade nicht in die EXE compilieren will.

Optimale Lösung, wie bereits vorgeschlagen worden ist: Erstelle eine reine Resourcen-DLL.

Code:

library ResLib;
 
{$R ResDLL.res} // erstellt mit "brcc32.exe ResDLL.rc"

begin
end.

Binde dort mit der ResDLL.rc -> ResDLL.res alle benötigten Icons, Bitmaps, usw. ein und die Strings entweder als ein Textfile (siehe RCDATA) mit den aufgelisteten Strings oder - fast noch einfacher - in der Struktur einer Stringtable.

Lade diese Resourcen-DLL dann dynamisch in das eigentliche Programm:

Code:

ResLibHandle := Loadlibrary(PChar(ResDLLfilename));

Mit diesem Handle lässt sich mit einem ResourceStream, einem LoadIcon(), LoadBitmap() bzw. einem GetResString() jede der verschiedenen Resourcen mühelos aus der Resourcen-DLL zur Verwendung im Programm herausholen

Durch einfachen Austausch der DLL gegen eine neue (mit gleichen Filenamen) und mit verschiedenen (aber mit jeweils gleichem Namen bezeichneten!) Resourcen ist die Aufgabe absolut flexibel, ohne großen Aufwand, schnell und unproblematisch gelöst.

Die Resourdcen-DLL kann ratz-fatz nach dem gerade aktuellen Bedarf erstellt werden, wozu allein nur die RC-Datei entsprechend verändert und als RES-Datei neu in die DLL eingebunden werden muss.

Das eigentliche Programm braucht für alle diese verschiedenen Resourcen-DLLs überhaupt nicht verändert zu werden.

[neo4a]

Zitat:

Zitat von ASM (Beitrag 1156696)

einfach nur sehr unprofessionell.

Es war (m)ein Vorschlag, die Sache etwas anders anzugehen. Wenn der Fragende etwas besser als Du darin geübt ist, sinnentnehmend zu lesen, wird er für sich schon die richtige Auswahl treffen.

[CCRDude]

Zitat:

Zitat von neo4a (Beitrag 1156705)

Es war (m)ein Vorschlag, die Sache etwas anders anzugehen.

Also wenn jemand Texte und Grafiken will, eine verschlüsselte Datenbank anzubieten, ist das auch mMn schon nicht mehr "die Sache" anders anzugehen, sondern eine ganz andere Sache anzugehen. Ich denke ASM hatte nur sofort des Eindruck, dass Du eigentlich gar nicht wirklich auf die Frage eingehen, sondern mit Deinem Wissen angeben willst. Dieser Eindruck ist auch bei mir irgendwie nicht gaz wegzuwischen ;)

[neo4a]

Zitat:

Zitat von CCRDude (Beitrag 1156707)

mit Deinem Wissen angeben willst. Dieser Eindruck ist auch bei mir irgendwie nicht gaz wegzuwischen ;)

Wenn Du - wie ich - unter "angeben" meinst, dass ich meine Sichtweise nicht für mich behalten möchte, dann brauchst Du Dir nichts weg zu wischen, dann ist das durchaus beabsichtigt ;) Und was das "asm" angeht, so wäre es IMO gut, wenn er es so hält wie bisher und nur sporadisch postet: Blockwart- Attitüden ala "ich sag jetzt mal was Sache ist" sind irgendwie dämlich. Da hilft es auch nicht, als erster das Wort professionell in den Mund zu nehmen. Das ist es nicht.

Zur Sache selbst: Mein Ansatz zielt nicht nur auf eine DB-Lösung, sondern auf einen "Daten-Eimer". In Erweiterung zu der Resourcen-Lösung hat die Zip-Lösung ein paar Vorteile: Inhalte werden komprimiert und bei Bedarf verschlüsselt, können bei Bedarf sehr einfach ausgetauscht werden, bieten eine interne Ordnerstruktur und aus Delphi-Sicht steht alles über Streams zur Verfügung. Man braucht weder ein MS-SDK (hat der Borland-Res-Compiler noch das Problem mit den Grafiken? Ich benutze ihn seit Jahren nicht mehr.), noch muss man mit einem Res-Viewer hantieren.

Das Einbinden in die Exe war nur als Initialisierung bei z.B. portablen Apps gedacht. Meinetwegen kann man es auch im Setup einpacken.

Und wenn ich mir es recht überlege, kann man das auch schon aus dem angemaulten Post entnehmen. Wenn man kann. Schau halt nach.

[tcoman]

Ich glaube nicht, dass ein Forum ein pures Frage- und
Antwortspiel sein sollte.

neo4a hat weitere Information geliefert, ohne erst den
Rest der ehrenwerten DP-Gemeinde zu kontaktieren.

ASM hat exakt das beantwortet, was gefragt wurde. Er
ist ein guter Zuhoerer und das bewiesen.

Unverstaendlich, dass er nicht ganz so geniale Menschen
runtermachen muss.

@Luckie
Jetzt kriege ich bestimmt wieder eine Nachricht, die
Leichen im Keller zu lassen.

[Luckie]

Ich will hier ja niemanden enttäuschen. Aber was soll der Unsinn? Dein Beitrag hat in keinster Weise etwas zum Problem beigetragen. Im Gegenteil, er geht auf das persönliche Verhalten von Forenmitgliedern ein. Und a das Thema schon seit drei Jahren durch ist, ist das mehr als überflüssig.

Und bevor es hier so weiter geht, mache ich den Thread zu. Musste das sein? :roll: