Jump to content
A.M. Hoornweg

tImageCollection in COM DLL - EXE needs manifest ???

Recommended Posts

Hello all,

 

I am using tImageCollection and tVirtualImageList inside a COM DLL to display some images on buttons etc.  This COM DLL is an update to an existing version - the calling processes are existing programs, many of which were compiled with older Delphi versions.

 

I'm observing a very strange phenomenon: the images on the buttons in the DLL are not displayed if the calling executable does not have a manifest.  They are only displayed if the calling executable has a manifest. I find no reference in the Delphi documentation that tImageCollection has manifest requirements.

 

Can anyone shed some light on this?

 

My reason for asking: I cannot update the existing legacy applications with a new manifest - they are digitally signed and inserting a new manifest would break the signature.. 

Share this post


Link to post
4 minutes ago, A.M. Hoornweg said:

find no reference in the Delphi documentation that tImageCollection has manifest requirements.

You mean this reference at https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Controls.TImageList:

Note: Image lists depend on Comctl32.dll. If the system does not have the latest version installed, there may be problems getting images to appear.

Share this post


Link to post
9 minutes ago, Lajos Juhász said:

You mean this reference at https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Controls.TImageList:

Note: Image lists depend on Comctl32.dll. If the system does not have the latest version installed, there may be problems getting images to appear.

The problem isn't tImageList related - the DLL used tImageList in the past without problems or manifest requirements until I replaced it with tImageCollection & tVirtualImageList.

 

Also, the operating system is Windows 10, so comctl32 on the system is most certainly the current version.  By the way, with a properly manifested application, the new icons display correctly even on Windows XP which is vintage so I don't think it's a matter of an outdated comctl32.

 

( edit: I compiled the test application under Delphi 11 fixpack 1 with {$SETPEOSVERSION 5.1} {$SETPESUBSYSVERSION 5.1} to make it work on XP).

Edited by A.M. Hoornweg

Share this post


Link to post
24 minutes ago, A.M. Hoornweg said:

Also, the operating system is Windows 10, so comctl32 on the system is most certainly the current version.

Not if the comctl v6 manifest hasn't been activated in your thread. You'll have comctl v5.8.

 

You need to activate the comctl v6 manifest whenever your DLL is called and deactivate whenever it returns. Every function should activate on entry, deactivate on exit. 

 

I do this in my Excel com add in. 

  • Like 1

Share this post


Link to post
3 hours ago, David Heffernan said:

Not if the comctl v6 manifest hasn't been activated in your thread. You'll have comctl v5.8.

 

You need to activate the comctl v6 manifest whenever your DLL is called and deactivate whenever it returns. Every function should activate on entry, deactivate on exit. 

 

I do this in my Excel com add in. 

 

Oww, that sounds like a pain.   But I think it should be possible to just pack a manifest alongside an existing application, without embedding it and damaging the digital signature?

Share this post


Link to post
17 minutes ago, A.M. Hoornweg said:

 

Oww, that sounds like a pain.   But I think it should be possible to just pack a manifest alongside an existing application, without embedding it and damaging the digital signature?

Well you likely will break the existing app. It's easy to do what I described. 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×