6

I have a form with many custom firemonkey components where each contain multiple bitmaps (loaded from PNG image files). Every time the form is saved, the binary data of the PNG images change in the FMX file!

This messes up my version control log (SVN), as changing just one property in the form results in thousands of changed lines.

Is there any way I can avoid this?

See screen shot from SVN diff here: :

SVN diff here

When the form was saved, the DotInlay.PNG image was not changed by me, and not even the control that contained the image had any changes .

Edit: From the comments, this is a bug in Delphi, so I created a new QP report: https://quality.embarcadero.com/browse/RSP-11259

Vote for it if you find it should be solved.

Community
  • 1
  • 1
Hans
  • 2,220
  • 13
  • 33
  • 2
    Related issue [Delphi TImageList bitmap changes](http://stackoverflow.com/questions/10744505/delphi-timagelist-bitmap-changes) Linkes QC was closed as "Won't Do" – Dalija Prasnikar Jun 03 '15 at 08:06
  • The only thing you can do is not to commit those changes to repository, and revert them when they happen. – Dalija Prasnikar Jun 03 '15 at 08:07
  • 1
    @DalijaPrasnikar Yes, when I worked with VCL before, it also happened, but that was only one line being changed for each image, and I could live with that. Now with Firemonkey it is all lines in the binary data that are changed. – Hans Jun 03 '15 at 08:16

1 Answers1

3

The IDE is just like that. One of the perils of putting binary resources into a .dfm/.fmx files. I don't believe that there is anything that you can do. Only Embarcadero can change their IDE.

What you have to do with .dfm/.fmx file and source control is to review carefully every commit and revert unintended changes. You need to do that no matter what because the IDE does have a habit of changing things that should not be changed. Even for non-binary resources.

My recommendation though is that you don't put images in .dfm/.fmx files. Keep them in resources. That way you can put the image file into the revision control and have it linked as a resource to your executable. You'll need to do more work in your code to load up the resource at runtime, but you can wrap that in helper methods if needed and each image load should be reduced to a one-liner.

The real benefit of this approach is that you exert better change control over your binary assets.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • It seem to happen with only half of the images, so I wonder what made the other half not change on every save... – Hans Jun 03 '15 at 08:13
  • 3
    Who knows. You could try petitioning Embarcadero to change, but I doubt you'll have much luck there. – David Heffernan Jun 03 '15 at 08:18
  • 1
    Actually the PNG streaming under FMX is done by an operating system routine (WIC). So any change of or inside the OS can cause this. – Uwe Raabe Jun 03 '15 at 08:33
  • @UweRaabe Emba could only create a new streaming representation in the eventuality that the image was changed – David Heffernan Jun 03 '15 at 08:38
  • 1
    @DavidHeffernan, they should better not rely on the OS implementation when writing to DFM files. They actually don't do so in VCL. May be Hans can file a QP report? – Uwe Raabe Jun 03 '15 at 09:06
  • @UweRaabe I'll be happy to file a QP report, though I am sure it is not critical enough to be fixed - unless, someone can direct a very specific change that will make it easy and quick for Emba to fix it. – Hans Jun 03 '15 at 09:51
  • @Hans, it will rarely be fixed without that report. Perhaps someone can add a suggestion for that fix, but I hope that Emba can find one by itself. Honestly, our part is to report those bugs - not to provide a fix for it. – Uwe Raabe Jun 03 '15 at 10:11
  • 1
    @UweRaabe Yes, I know it sounds stupid, I just find bugs in Delphi on a daily basis, and if I should report them all with a MWE/SSCCE then it would be a full time job... I will find time to report this one. – Hans Jun 03 '15 at 11:02
  • @Hans, it will be hard (although not impossible) to provide such thing as an MWE/SSCCE for this one as it may rely on the OS creating the DFM and the one which emits the changes. I would rather go with a phrase like "Don't use OS specific formats when writing DFMs, because they will differ without need". It is more like when told "Don't touch the oven, because it is hot" you don't need to prove it with your own hand. – Uwe Raabe Jun 03 '15 at 11:27
  • As Dalija pointed out, this appears to be related to [this QC](http://qc.embarcadero.com/wc/qcmain.aspx?d=92769) which probably won't be fixed. – Leonardo Herrera Jun 03 '15 at 13:42
  • As it seems from the QC that @LeonardoHerrera posted, it is a Microsoft issue, so I doubt that it will ever get fixed... – whosrdaddy Jun 04 '15 at 06:40
  • What are you people talking about? What the blazes is wrong with leveraging the OS supplied functions? This is *not* an IDE issue... in fact the IDE is only involved insofar as telling the *live* real, runtime component instances on the form to stream themselves out. In fact, the same thing would happen at runtime because the code isn't IDE code. The VCL image list component also uses the OS streaming. If the image is changing each time, then yes, there is some reason down in the OS. – Allen Bauer Jun 04 '15 at 18:02
  • Putting the image in an external file instead of the DFM will steal away from you the WISIWYG concept (that Delphi brags so much about it). – Gabriel Jan 18 '21 at 11:55
  • @InTheNameOfScience Yes, but that's only really because the Delphi IDE is unable to separate these assets from its form files. Given that it is, you have a "lesser of two evils" choice to make. That choice is ultimately down to the individual. – David Heffernan Jan 18 '21 at 12:15