I needs ideas on how to track-down / solve this problem:
I have a potential customer who states that on Windows 7 32bit my software is giving this error:
imagelist Failed to read ImageList data from stream
Person has given this additional information:
(Quick note for those who not aware - since WinXP both versions have shipped as default)
...
The executable is built using XE4 on a themed Windows 10 and works on at least (own tested)
My TImagelist is set to "cdDeviceDependent" (which corresponds to ILC_COLORDDB)
...
This is my manifest extracted from my executable using a resource explorer:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
</compatibility>
</assembly>
...
TODO
I have noticed in documentation that for ImageList_WriteEx is states: "You should not create an image list that is written with the ILP_DOWNLEVEL flag with ILC_COLOR32" ...
I am not sure what happens when compiling on a 32bit-color system using "ILC_COLORDDB" as value?
My thinking is/was that ILP_DOWNLEVEL would possible be ignore... And thus more likely to fail when read by 5.x ComCtl32 ? But I have not been able to find any such cases described on the internet, but...
Also it appears my executable works on a virtual Win7-SP1-32bit-16color-classic-themes configuration...
...
TODO
Send a debug tool to fetch/confirm the actual version loaded on comctl32.dll
...
TRIED
I have tried pointing the user to an old version with a manifest without the **compability section. That did not make any difference.
By default the ComCtl32 version on Windows 7 is 5.82 and not 6.x.
So you will have to modiffy your manifest acordingly to allow use Comctl32 version compatible with Windows 7.
That is of course if your application isn't using some feature that isn't present in ComCtl32 version 5.82. If it does then you will have to implement some workarround to it or simply remove Windows 7 from officially supported platforms for your application.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.