Hi guys. I'm trying to solve an odd problem with PNG components in a DLL expert, and I'm stuck. Any ideas? Details are:
Hi guys. I'm trying to solve an odd problem with PNG components in a DLL expert, and I'm stuck. Any ideas? Details are:
I've got a couple of bug reports for the Bookmarks plugin that when PngComponents (http://cc.embarcadero.com/item/26127) are installed in XE2, trying to do something like (at designtime) load a PNG file in the a TPngBitBtn's PngImage property fails with an exception "Invalid graphic format". I can reproduce this, and it works fine when the plugin is not installed, so having the expert present is definitely the cause. According to one of the bug reports it doesn't happen in other IDE versions, just XE2.
Debugging it under the IDE itself doesn't help - the call stack is:
[20FE00D4]{designide160.bpl} PicEdit.TGraphicProperty.Edit (Line 272, "PicEdit.pas" + 10) + $12
[20878DB6]{coreide160.bpl} PropInsp.TPropertyInspector.PropListEditDblClick (Line 871, "PropInsp.pas" + 18) + $12
[2111DA0D]{vclide160.bpl} IDEInspListBox.TInspListBox.DoEditDblClick (Line 620, "IDEInspListBox.pas" + 2) + $A
[2111F7E7]{vclide160.bpl} IDEInspListBox.TInspListBox.ListButtonClick (Line 1311, "IDEInspListBox.pas" + 2) + $2
[50332EEB]{vcl160.bpl } Vcl.Controls.TControl.Click (Line 7320, "Vcl.Controls.pas" + 9) + $8
etc.
For a while I thought I had it solved: I thought that since I use PNG images in the DLL, and so the VCL's own PNG code is linked in (I don't use PngComponents, just the default RTL PNG code), the DLL's copy of Vcl.Imaging.PngImage is registering itself with TPicture and it's incompatible with the PngComponents version. Normally a DLL is stand-alone, but it was a working hypothesis. However, building the DLL with a custom version of PngImage.pas with the registration code disabled and all initialization-time PNG handling deferred doesn't solve it. Building with PngComponents does, but presumably this means that (if the TPicture registration etc is the cause) using the DLL expert causes the IDE to use the version of PngComponents in the DLL, not the version the user has installed. That's if I'm even on the right track about the cause. A DLL shouldn't normally integrate with the IDE's type / registration / etc systems at all - avoiding that is one of the reasons to use a DLL for a plugin instead of a BPL.
Does anyone know what the cause might be, and how I might solve this? My ideal solution would be to build using the RTL default PNG code, and not have or cause any incompatibility with PngComponents.
Googling for the error with PngComponents shows some stuff, but nothing that seems to be applicable to the DLL / host problem.
http://cc.embarcadero.com/item/26127
I've got a couple of bug reports for the Bookmarks plugin that when PngComponents (http://cc.embarcadero.com/item/26127) are installed in XE2, trying to do something like (at designtime) load a PNG file in the a TPngBitBtn's PngImage property fails with an exception "Invalid graphic format". I can reproduce this, and it works fine when the plugin is not installed, so having the expert present is definitely the cause. According to one of the bug reports it doesn't happen in other IDE versions, just XE2.
Debugging it under the IDE itself doesn't help - the call stack is:
[20FE00D4]{designide160.bpl} PicEdit.TGraphicProperty.Edit (Line 272, "PicEdit.pas" + 10) + $12
[20878DB6]{coreide160.bpl} PropInsp.TPropertyInspector.PropListEditDblClick (Line 871, "PropInsp.pas" + 18) + $12
[2111DA0D]{vclide160.bpl} IDEInspListBox.TInspListBox.DoEditDblClick (Line 620, "IDEInspListBox.pas" + 2) + $A
[2111F7E7]{vclide160.bpl} IDEInspListBox.TInspListBox.ListButtonClick (Line 1311, "IDEInspListBox.pas" + 2) + $2
[50332EEB]{vcl160.bpl } Vcl.Controls.TControl.Click (Line 7320, "Vcl.Controls.pas" + 9) + $8
etc.
For a while I thought I had it solved: I thought that since I use PNG images in the DLL, and so the VCL's own PNG code is linked in (I don't use PngComponents, just the default RTL PNG code), the DLL's copy of Vcl.Imaging.PngImage is registering itself with TPicture and it's incompatible with the PngComponents version. Normally a DLL is stand-alone, but it was a working hypothesis. However, building the DLL with a custom version of PngImage.pas with the registration code disabled and all initialization-time PNG handling deferred doesn't solve it. Building with PngComponents does, but presumably this means that (if the TPicture registration etc is the cause) using the DLL expert causes the IDE to use the version of PngComponents in the DLL, not the version the user has installed. That's if I'm even on the right track about the cause. A DLL shouldn't normally integrate with the IDE's type / registration / etc systems at all - avoiding that is one of the reasons to use a DLL for a plugin instead of a BPL.
Does anyone know what the cause might be, and how I might solve this? My ideal solution would be to build using the RTL default PNG code, and not have or cause any incompatibility with PngComponents.
Googling for the error with PngComponents shows some stuff, but nothing that seems to be applicable to the DLL / host problem.
http://cc.embarcadero.com/item/26127
I have the same issue with imagen and png components both installed. Seems to be a naming conflict.
ReplyDeleteUwe Raabe Thanks for the heads up about GLScene - They have named that method right!
ReplyDeleteUwe Raabe That looks very useful, thanks. Lots of hacking to access things at particular offsets, I see. Good to have that already worked out :)
ReplyDelete