Wie Image aus VCL-Formular-Datei (.dfm) auslesen

[Harry Stahl]

Zitat von Sir Rufo:

Eventuell hilft ja dieser Link weiter

DFM Parser and Search Utility

Nein, leider nicht, das Programm sucht nur nach entsprechenden Komponenten, manipuliert sie aber nicht. Dennoch danke für den Link.

[Bernhard Geyer]

Zitat von Harry Stahl:

Wenn man z.B. 100 oder mehr TSpeedButtons in einer Form hat, mit entsprechenden Glpyhs, wäre es schon ein irrer Aufwand, hinterher manuell die Bitmaps bearbeiten zu müssen, das will ich mir halt ersparen

Sind das auch 100 unterschiedliche Icons oder doch viele Icons mehrfach verwendet.
Ich würde mir ein zentralen Icon/Image-Pool aufbauen und in jedem Formular sich bei diesen bedienen.

[Union]

Leider weiß ja nur die Komponente selber, wie die binären Daten codiert sind. Es gibt da ja auch unterschiedliche Property-Namen, z.b. Picture, Bitmap, Image.Data, Glyph etc.

Ich würde das wie folgt lösen: Eine Designtime Komponente erstellen mit einem Editor, die keine Persistenz hat. Die beinhaltet dann einen Editor der über das Verb aufgerufen wird. In diesem Editor durchläufst Du alle Komponenten des Formulars und liest die Image-Objekte in eine Liste ein wobei Du Dir merkst welche Property welches Objekts das war. Die Listeneinträge kannst Du dann evtl. visualisieren, markieren und zur Konvertierung bestätigen. Daraufhin das Format entsprechend wandeln und die Komponenten-Eigenschaften aktualisieren.

Für die Umstellung eines Formulars müsstest Du zunächst die BPL installiert haben. Dann nur die Komponente fallen lassen, draufklicken und die Konvertierung bestätigen. Dann die Komponente wieder löschen und nächstes Formular. Alternativ könnte man natürlich auch einen Experten schreiben.

[Harry Stahl]

Zitat von Bernhard Geyer:

Die Daten sind Hex-Codiert.
In deinem Beispiel steht TBitmap + den Binärstream des Bitmaps drin.

Ja, das stimmt, kann ich nun so bestätigen.

Handelt es sich z.B. um ein TSpeedButton mit einem Glyph, dann beginnt in dem Datenstream ab Offset 5 das eigentliche Bitmap. Vorher sind 4 Bytes, die Delphi anscheinend intern für die Komponente verwendet (nennen wir das mal "Komponentenheader"). So kann ich also ohne Probleme die Bitmap ab Position 5 auslesen.

Das Problem entsteht nun, wenn ich eine geänderte Bitmap zurückschreiben will. Denn die ersten 4 Bytes unterscheiden sich, je nach dem, welche Bit-Tiefe und welches Ausmaß die Bitmap hat. Eine echte Logik konnte ich da selber leider nicht erkennen.

Ist jemanden eine Beschreibung bekannt, nach welcher Systematik die ersten 4 Bytes in dem Stream ("Komponentenheader") für "Glpyh.data" (Tspeedbutton), "Picture.data" (TImage) oder "Bitmap" (TImagelist) geschrieben werden müssen?

[Bernhard Geyer]

Ich würde sagen das ist die Längenangabe:
In deinem Fall: E6040000
Intel (Little-Endian) Reihenfolge, also 000004E6 = 1254 Byte Datenlänge

[Harry Stahl]

Nein, Größenangaben können das m.E. nicht sein.

Ein 16x16 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als "Komponentenheader":

Code:

 Glyph.Data = {
    36030000...

Ein 16x16 großes 32-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
    36040000...

Ein 24x24 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
   F6060000...

[Bernhard Geyer]

Zitat von Harry Stahl:

Nein, Größenangaben können das m.E. nicht sein.

Ein 16x16 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als "Komponentenheader":

Code:

 Glyph.Data = {
    36030000...

Ein 16x16 großes 32-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
    36040000...

Ein 24x24 großes 24-Bit-Bitmap hat z.B. diese 4 Bytes als Header:

Code:

 Glyph.Data = {
   F6060000...

Wieso nicht?

16*16*24 Bit = 768 Byte <-> 0x0336 -> 822 Bildaten inkl. den 54 Byte BMP-Header
16*16*32 Bit = 1024 Byte <-> 0x0436 = 1078 Bildaten inkl. den 54 Byte BMP-Header
24*24*24 Bit = 1728 Byte <-> 0x06F6 = 1782 Bildaten inkl. den 54 Byte Bmp-Header

[Harry Stahl]

Lässt erst mal ein wenig Hoffnung aufkommen

Wobei ich festgestellt habe, dass bei einem 16x16 großen 32-Bit-Bitmap auch dies dort stehen kann:

Code:

Glyph.Data = {
     36080000...

(der Bitmap-Stream ist dann auch 2102 Byte groß)

also, statt dem

Code:

Glyph.Data = {
  36040000...

Anscheinend können 32-Bit-Bitmaps, 16x16 Size auch unterschiedlichen Speicherbedarf annehmen, dachte die wären bei gleichem Ausmaß und Bit-Tiefe immer gleich groß.

[Harry Stahl]

Hast Du noch einen Tipp, wie ich die Größe des Streams (Integerwert) in den HEX-Wert, Little Endian-Reihenfolge konvertiere? Gibt es dafür eine fertige Funktion?

[Bernhard Geyer]

Zitat von Harry Stahl:

Lässt erst mal ein wenig Hoffnung aufkommen

Wobei ich festgestellt habe, dass bei einem 16x16 großen 32-Bit-Bitmap auch dies dort stehen kann:

Code:

Glyph.Data = {
     36080000...

(der Bitmap-Stream ist dann auch 2102 Byte groß)

Das müsste ich dann man mit einem eigenen Delphi und einer Vollständigen Hexwert (in einem Beispielformular) nachvollziehen.