RAD Studio 2009 and later - Make TdxPNGImage class registration optional for loading PNG images

Sorry for the delay. Had some vacation.

Yes, I have no idea why but it works :) Makes live easier with ReportBuilder. THX !!

Very bad, this behaviour. I just bought and installed the dx components to realize, that all my dx-unrelated projects' uses-clauses are spammed with this nonsense.

Why do you bloat code in all my applications, that don't even use dx?
Suddenly the executable sizes increase and I get dependency errors with absolutely no gain.

I don't see a valid background-reasoning to have it altogether, you should get rid of your own baked png.
Very annoying.

… and with each new version I have to reset this stupid thing…  Just again today…

Sven

It is possible to make it default in installer (or detect previous change of source)?

Hello,
I'm afraid we have no plans to implement this feature in our Installer.

The problem is that this DEFINE has to be changes manually with every update and cannot be undefined externally. That's error prone (and pain). It would be much easier if you flip the meaning of that switch. Call it NO_DXREGISTERPNGIMAGE (and adjust where it is used) and leave it undefined (commented out). If I want to disable the dxPngImage I than could just define NO_DXREGISTERPNGIMAGE in my project. This would work if I have the source and can compile it with my project (but that's the default setup I use) and would survive your updates. The old way of editing dxGDIPlusClasses.pas would still work.

Another way (more complicated, but more powerful) would be using your global include-file (cxVer.inc) which could include a user/project specific include file. I use this technique very successfully where this user specific file can only be reached via the search path. Changing the search path I can change the used include file.

I have created a new ticket (Simplify the process of making the TdxPNGImage class registration optional for loading PNG images) to improve the current installer behavior. We will possibly implement this functionality with future versions of our controls.

Hello Steffen,
Making the TdxPNGImage class registration optional for loading PNG images is a very rare task. Before we consider the possibility of implementing the Simplify the process of making the TdxPNGImage class registration optional for loading PNG images ticket, would you please clarify in detail why it is necessary for you to suppress the TdxPNGImage class registration?

I cannot believe DevExpress is so reluctant to do this.  I work on many projects for different teams.  I have DevExpress licensed and installed.  However, many of the projects that I work on (which each have different team members) do not have DevExpress and those projects do not use DevExpress components.

1. Create a new VCL project.  Place a TImage on the form.  Load a JPEG or PNG.  Save project.  Have another team member, who does not and never will have DevExpress installed, try to build the project.  Compile error because a dxGDIPlusClasses is obviously not installed.  Remove that unit from the uses clause.  Build and run project.  Image previously loaded at design-time does not appear when project executes.  When image was loaded at design-time, it was loaded with a registered file format that does not exist when DevExpress is not installed.
2. Back on the workstation with DevExpress installed, remove dxGDIPlusClasses from the uses clause using a text editor.  Build project in Delphi, ensuring the form is not opened in the designer (because the uses clause will be updated).  Run the project.  The image does not appear when project is executed because even though TdxPNGImage was registered at design-time, it is not registered at run-time (since dxGDIPlusClasses is not in uses clause).
   Overriding the design-time file format class causes every image loaded at design-time to be mapped to a DevExpress class.  Developers who do not have DevExpress installed (and never will) cannot work on projects WHICH DOE NOT USE A SINGLE DevExpress component if another team member does have DevExpress installed.
   Luckily, I build all third-party components from source.  So I turned off the DXREGISTERPNGIMAGE compiler conditional in dxGDIPlusClasses and rebuilt the dxGDIPlus run-time package.  (Note the package name and properties indicate it is a RUN-TIME package.  Nonetheless, it registers classes and changes the design-time behavior of the Delphi IDE.  That's poor package design.  Anything that affects the design-time behavior of the IDE should be placed in a design-time package.)
   However, that still wasn't enough.  Although my IDE stopped adding dxGDIPlusClasses to the uses clause and other team members could compile the project, images still were not appearing.  That's when I remembered that when I previously loaded the images at design-time, the image was registered with a DevExpress class.  I removed and added back each image, which finally solved the problem.
   I purchased the Express GridPack because I needed the PivotGrid component.  That's it.  Just one component.  I paid a lot of money for that one component.  I justified the expense based on the excellent reviews and opinions of DevExpress components and support.  Based on the three support tickets that I have opened in the last two weeks, I do not share those opinions.

Having problems with other components sets adding their stuff to the uses clause I solved it by creating a dummy empty units with the required names. Maybe this scenario can solve your problem.
Create empty unit named dxGDIPlusClasses and send it to the developers not having Devex installed. It should be out of  VCS of course.

Hello Jon and other guys tracking this ticket.

We totally understand that registering our own class for TPicture editors can cause problems in such scenarios as Jon has described above. Let me elaborate on why we had to do so. The fact is that we have implemented the PNG support for these IDEs, which did not support it by default. Since almost all our products require PNGs for displaying purposes, and we still support very old IDEs (Delphi 7 and Delphi 2007), we still have to register our class as default. Perhaps, once we drop support for old IDEs, we will improve the current mechanism. We appreciate your understanding.

This just bit me again, as I had forgotten to undefine DXREGISTERPNGIMAGE after my last DevExpress upgrade.  This cost me and my team about an hour of time, as I had checked in units that now had images registered with the DevExpress classes.  An hour may not seem like much, but it was very frustrating nonetheless.
If the primary reason the PNG classes are registered is to support older IDEs that do not include PNG support, why not change the dxGDIPlus package so that it only registers the DevExpress classes for the IDE versions that do not include PNG support?

Hello Jon,

Old IDEs is the main, but not the only reason for registering our own PNG processing. I discussed the possibility of avoiding this registering with our developers several times, but this task requires some additional research. The point is that we are not sure that the default VCL class can handle PNG images as good as our own class do. We remember that when we were working on our skin engine, a standard PNG class could not correctly display some images. Without additional research, we cannot be sure that the situation is better now. Anyway, in 15.1, we are going to drop support for old Delphi 7 and 2007 IDEs, so I think that it is a good time to consider switching to standard PNG or at least implementing the Add an option to Installer to simplify the process of making the TdxPNGImage class registration optional for loading PNG images feature. I will remind our developers of this problem, so we will possibly apply necessary changes to 15.1.

It's unbelievable! It's like former times when software changes some dll-files in the OS.
I'm developing with Intraweb and since days(!) I have effects with images on the IWForms which now I think it's because of these changes.
I'm very annoyed!

Hello Peter,

Please accept my apologies for the inconvenience. At that time, it was the only way for us to implement PNG support for old IDEs that do not provide PNGs by default. Now, when modern IDEs support PNG out of the box, we will consider getting rid of registering our own PNG handling mechanism.
In the meantime, please recompile our controls with the disabled DEFINE directive as described above.

Hello Paulo,
I have done what you advised. I have installed version 13.2.8, after that I removed the registration and installed it again in recompile mode. Even I reinstalled the Intraweb package. The result is the same: Error message "TdxSmart Image can not be assigned to TPngImage". It seems that nothing has changed.
What can I do to?
(I suspect that it has something to do with the dialog to open an image: old image which are placed under Delphi2007 had worked and are working still under Delphi XE3. How can I deactivate the image picker which I assume that it's from DevExpress)

Hello Peter,

This looks strange. I have tested the following approach on my side and it works OK:

1. Installed VCL 13.2.8 onto my Delphi XE IDE.
2. Opened the <DevExpressInstallatioFolder>\ExpressGDI+ Library\Sources\dxGDIPlusClasses.pas file.
3. Applied the following changes to that file.

Delphi
{$I cxVer.inc}  
//{$DEFINE DXREGISTERPNGIMAGE}  
 interface  

4. Saved the file and ran our Setup.exe in Recompile mode.
5. After the compilation was finished, I launched my IDE, created a new application, and placed the TImage control on the main form.
6. Loaded the PNG picture into the TImage.Picture property.
7. As a result, I see the TPngImage class in my Object Inspector (see the attached image).

Please ensure that you performed all these steps on your side.

As for disabling our Icon Library image picker, you can go to Component->Install Packages… and disable the "Express Cross Platform Library Icon Library by Developer Express Inc." package there.

Hello Paulo,
I have done it again as you described: everytime with the same result. Then I removed the complete DevExpress Package and everything was fine. I reinstalled the VCL 13.2.8 as you described: again the same result: TdxSmartImage is everywhere.
Then I found the point (see attachment): there are two dxGDIPlusRS17.bpl files: one is old (and it would be not removed by deinstallation!) and this was the one the IDE has used. I took the newer one from DevExpress library and now it seems to work.
Now I hope I can install the TIWChart component, until now I had no success (and I tried it several times in the last few weeks). All in all I need round a week for this workaround! Please tell this your developers.
Thank you for your support.

Hello Peter,

Thank you very much for your reply. I am happy to hear that you have found the cause of this GDIPlus package update issue. I have reminded our developers about this problem once again after your post. So, I hope that we will find a way to avoid such problems with future versions of our controls.

Hello Paulo,
can you please disable this behaviour by default or make it as option in the setup. It is very annoying in case of updates!
Thanks in advance.

I have created a separate ticket (Add an option to Installer to simplify the process of making the TdxPNGImage class registration optional for loading PNG images) to provide the corresponding option in our Setup. We will possibly implement it in future Installers.

Please add my vote for this option.

Hi,  I've tried the workaround (commenting out  {$DEFINE DXREGISTERPNGIMAGE} in dxGDIPlusClasses.pas) then running my install package (15.1.3 in Rad Studio XE8) and it has made no difference. My GIF still won't animate and in the  object inspector the picture property of my TImage still shows as a TdxSmartImage? I've checked for all of the dxGDIPlus*.* files and there don't seem to be any loose ones lying around, all BPLs show 30/10/2015 as their modified date so they have been rebuilt.  Have I missed something here?,  thanks

Hello Willie,

After commenting the {$DEFINE DXREGISTERPNGIMAGE}  line in the dxGDIPlusClasses.pas file and running our Setup in Recompile mode, existing projects are not changed. Only packages are recompiled. Thus, to change the TImage image' class, it is necessary to reload this image from a file. Otherwise the loaded image will be still of the TdxSmartImage class. Please test this step-by-step algorithm:

1. Install VCL 15.1.5.
2. Open the <DevExpressInstallatioFolder>\ExpressGDI+ Library\Sources\dxGDIPlusClasses.pas file.
3. Apply the following changes to that file.

Code
{$I cxVer.inc}  
//{$DEFINE DXREGISTERPNGIMAGE}  
 interface  

4. Save the file and run our Setup.exe in Recompile mode.
5. After the compilation is finished, launch your IDE, create a new application, and place the TImage control on the main form.
6. Load the PNG picture into the TImage.Picture property.
7. As a result, you will see the TPngImage class in your Object Inspector.
   Please keep me informed of your progress.

Hi, Can you please explain why this only works for Rad Studio 2009 plus, and not for Delphi 7? Thanks

Hello Rael,

This approach cannot work in Delphi 7 because PNG images are not supported in this IDE by default.

I tried to diable the SmartImage Feature (it produces a lof of problems with the ReportBuilder). But everytime I disable DXREGISTERPNGIMAGE the setup will enable it (i tried it with readonly attribute).

How can I disable this feature in Delphi Seattle?