Wieso ändert Delphi die Icons?

[ken_jones]

Mir ist aufgefallen, dass bei meinen 2 Delphi XE5 Installationen folgendes passiert:

Wenn ich ein Projekt mit z.B. einem Speedbutton mit Icon bei GitHub einchecke, dann auf einem anderen PC mit derselben XE5 Lizenz öffne, builde, speichere und wieder bei GitHub einchecke, so wird im DFM immer eine Differenz im Byte 8 des Icon Bytestream festgestellt. z.B. wird aus B0 eine B4.

Was fummelt da Delphi rum? Ist das eine art Kopierschutz? Oder versteckte Information über den Compiler, rsp. PC auf welchem compiliert wird?

Ist nicht wahnsinnig wichtig, nimmt mich einfach wunder.

[Union]

Hängt von den installierten comctl dll ab und damit indirekt auch mit dee IE Version. Bei Imagelisten ist es auch so.

[ken_jones]

Danke für die Info, das beruhigt irgendwie wieder. Werde somit mal die DLLs prüfen. Aber so wirklich Sinn gibt das ganze trotzdem nicht...

[jaenicke]

Normalerweise checkt man ja ohnehin nur gewollte Änderungen ein. Und so etwas verwerfe ich beim Einchecken direkt wieder, deshalb stört mich das auch nicht sehr.

[Sherlock]

Das haben wir hier in der Firma auch, die DFMs werden deshalb von uns beim Commit fast immer verworfen. Gewollt ändert sich da ja selten wirklich was. Ist allerdings eine nervige Sache, denn einen wirklich guten Grund für dieses absonderliche Verhalten gibt es ja nicht, oder doch?

Sherlock

[Bernhard Geyer]

Wäre es möglich Beispielhaft 2* den Icon Bytestream zu posten?
Mithilfe der definition des Icon-Formats und einem Hex-Editor sollte sich doch wohl das Problem erklären lassen.

[ken_jones]

Zitat von Bernhard Geyer:

Wäre es möglich Beispielhaft 2* den Icon Bytestream zu posten?

Gerne, hier aus dem heutigen Git Abgleich:

Code:

@@ -6781,7 +6857,7 @@ object frmMain: TfrmMain
     Left = 616
     Top = 112
     Bitmap = {
-      494C010101000800C40010001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
+      494C010101000800C80010001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
       0000000000003600000028000000400000001000000001002000000000000010
       0000000000000000000000000000000000000000000000000000EFE5D800A877
       2E00A8762E00A8772E00A8772E00A9772E00A9772E00A8772E00D3BB96000000
@@ -6964,7 +7040,7 @@ object frmMain: TfrmMain
     Left = 592
     Top = 296
     Bitmap = {
-      494C010102000800100110001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
+      494C010102000800140110001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
       0000000000003600000028000000400000001000000001002000000000000010
       0000000000000000000000000000000000000000000000000000000000000000
       00000000000001079F000313A9000418AE000419AE000313A9000108A0000000

[himitsu]

Zitat von http://en.wikipedia.org/wiki/BMP_file_format:

reserved; actual value depends on the application that creates the image

Zitat von http://msdn.microsoft.com/en-us/library/windows/desktop/dd183374.aspx:

WORD bfReserved2;

Vielleicht speichert MS dort seine API-Version, oder sowas.


Am aller Schönsten ist das ja bei ImgesListen, wenn sich da ab und an hunderte Zeilen ändern.

- einfach verwerfen, wenn man weiß, daß man dort nichts verändert hat (gibt keinerlei Probleme, solange man das im gesamten Stream zurücksetzt)
- oder einfach mal mit einchecken und man hat wieder ein paar Tage lang seine Ruhe

[Bernhard Geyer]

Zitat von himitsu:

Zitat von http://en.wikipedia.org/wiki/BMP_file_format:

reserved; actual value depends on the application that creates the image

Zitat von http://msdn.microsoft.com/en-us/library/windows/desktop/dd183374.aspx:

WORD bfReserved2;

Vielleicht speichert MS dort seine API-Version, oder sowas.

Dann wäre die Frage mit welcher Windows-Version die Checkins gelaufen sind.
Und was passiert wenn man mal mit Z.B. Win8.1 eingecheckt hat ob beim nächsten mal auch wieder sich der Wert ändert.

[jbg]

Zitat von himitsu:

Vielleicht speichert MS dort seine API-Version, oder sowas.

Das ist nicht die API-Version sondern das Feld "WORD cGrow", das auf Basis von "cCurImage" (Aktuelle Anzahl) und "cMaxImage" (Capazität) bei jedem Laden (nicht beim Speichern) neu berechnet wird. Wenn man eine ImageListe lädt, dann ist nicht mehr identisch mit den Daten aus dem Stream.

(Struct von WINE stibitzt)

Code:

#define IMAGELIST_MAGIC 0x53414D58

/* Header used by ImageList_Read() and ImageList_Write() */
#include "pshpack2.h"
typedef struct _ILHEAD
{
    USHORT      usMagic;
    USHORT      usVersion;
    WORD        cCurImage;
    WORD        cMaxImage;
    WORD        cGrow;
    WORD        cx;
    WORD        cy;
    COLORREF    bkcolor;
    WORD        flags;
    SHORT       ovls[4];
} ILHEAD;