Thank you for making this tool. It is a great help to avoid messing up version control. Only problem left is that Delphi re-encodes PNG images in the .FMX form files every time it saves the form. This causes thousands of changed lines every time I change a single property in a form. It would be great if that could be avoided too? I made a SO question about it once: stackoverflow.com - Why does Delphi XE7 change PNG image on every FMX form save?
Nicholas Ring Not in the moment - probably never. XE still uses the old unit names (those without System and VCL in front), which requires either IFDEFs in the uses clauses or making use of unit scope names. Both are techniques I avoid at all cost. Usually XE2 is the lowest version my plugins support.
David Heffernan Yes, that would be the obvious work around. However, the form designer is made so you can design your app using a WYSIWYG interface and it is a pity that this small detail is working against it.
Uwe Raabe It is probably a remnant from the "Windows only" days. Since the .fmx file can be loaded on multiple platforms they must already have implemented another image framework to decode the images.
Hans Lavdal Jakobsen To me it looks more like the other way round. The VCL uses Vcl.Imaging.pngimage since PNG support was introduced in Delphi 2009, while FMX uses a codec manager where different codecs are registered depending on the platform. Due to the different TBitmap implementations of Vcl.Graphics and Fmx.Graphics and the dependency of Vcl.Imaging.pngimage from Vcl.Graphics there is no easy interchange between both frameworks. On the other hand, as the IDE is running under Win32 only, one could register a more stable conversion routine only for design time (probably based on the above Vcl.Imaging.pngimage), but due to some private nature of the implementing classes it is not so easy to intercept the storage of those images and use a better alternative.
Hans Lavdal Jakobsen It's better on many levels to keep the binary resources outside the form files.If you need to update them, then it's a nightmare through the IDE. I don't suffer from this issue but I still keep binary resources outside the form files.
Jeroen Wiert Pluimers OK, the previous normalizing process sorted the reference to an optionset before the import item of that optionset, so that it could not be resolved. A similar issue occurred when build events were used. These were sorted before the import of CodeGear.Delphi.Targets which defines some variables used inside build events. If none of these features were used there were no problems.
Any plans for an XE version?
ReplyDeleteThank you for making this tool. It is a great help to avoid messing up version control.
ReplyDeleteOnly problem left is that Delphi re-encodes PNG images in the .FMX form files every time it saves the form. This causes thousands of changed lines every time I change a single property in a form. It would be great if that could be avoided too?
I made a SO question about it once:
stackoverflow.com - Why does Delphi XE7 change PNG image on every FMX form save?
Don't put binary data on a form. Keep it in external resources. Then they can be properly versioned.
ReplyDeleteHans Lavdal Jakobsen Unfortunately that is far from easy to implement. I am probably not going to invest time in that.
ReplyDeleteNicholas Ring Not in the moment - probably never. XE still uses the old unit names (those without System and VCL in front), which requires either IFDEFs in the uses clauses or making use of unit scope names. Both are techniques I avoid at all cost. Usually XE2 is the lowest version my plugins support.
ReplyDeleteDavid Heffernan Yes, that would be the obvious work around. However, the form designer is made so you can design your app using a WYSIWYG interface and it is a pity that this small detail is working against it.
ReplyDeleteHans Lavdal Jakobsen FMX uses the WIC framework when running under Windows to convert from bitmap to PNG and vice versa. Seems that this conversion is not 100% transparent.
ReplyDeletehttps://msdn.microsoft.com/de-de/library/windows/desktop/ee719654(v=vs.85).aspx
Uwe Raabe It is probably a remnant from the "Windows only" days. Since the .fmx file can be loaded on multiple platforms they must already have implemented another image framework to decode the images.
ReplyDeleteHans Lavdal Jakobsen To me it looks more like the other way round. The VCL uses Vcl.Imaging.pngimage since PNG support was introduced in Delphi 2009, while FMX uses a codec manager where different codecs are registered depending on the platform. Due to the different TBitmap implementations of Vcl.Graphics and Fmx.Graphics and the dependency of Vcl.Imaging.pngimage from Vcl.Graphics there is no easy interchange between both frameworks.
ReplyDeleteOn the other hand, as the IDE is running under Win32 only, one could register a more stable conversion routine only for design time (probably based on the above Vcl.Imaging.pngimage), but due to some private nature of the implementing classes it is not so easy to intercept the storage of those images and use a better alternative.
So what was the problem it solved?
ReplyDeleteHans Lavdal Jakobsen It's better on many levels to keep the binary resources outside the form files.If you need to update them, then it's a nightmare through the IDE. I don't suffer from this issue but I still keep binary resources outside the form files.
ReplyDeleteJeroen Wiert Pluimers Are you referring to the bugs that are fixed in the new version?
ReplyDeleteUwe Raabe indeed. Something more detailed than "a problem when using option sets and/or build events"
ReplyDeleteJeroen Wiert Pluimers OK, the previous normalizing process sorted the reference to an optionset before the import item of that optionset, so that it could not be resolved. A similar issue occurred when build events were used. These were sorted before the import of CodeGear.Delphi.Targets which defines some variables used inside build events. If none of these features were used there were no problems.
ReplyDelete