Hello,
i'd just like to add one thing to consider:
On the forum it still happens not often, but regularly that someone
asks a question, and on the screenshot they show, it's clear that
their exe doesn't have a manifest. This usually happens when they
don't use one of the provided build solutions and they build a sample
from scratch and compile by hand.
Eric
Friday, November 11, 2022, 2:07:32 PM, you wrote:
TT> I can't think of use case for not using a manifest (but that certainly
TT> doesn't mean there isn't one).
TT> Maybe just start with the runtime version check for comctl32 v6 and log it
TT> as an error?
TT> This way a use case may be identified.
TT> If nobody ever complaints the code targeting comctl v5 could then be
TT> eliminated later on.
TT> And the check would have to be implemented anyway.
TT> VZ schrieb am Donnerstag, 10. November 2022 um 21:50:05 UTC+1:
>> Hello,
>>
>> I'm trying to get rid of the code required to support obsolete Windows
>> versions in wxMSW, but while doing it I've realized that in many places we
>> are actually checking (or should be checking, as it's done wrongly in some
>> places, e.g. HasNativeCommandLinkButton(), currently) for comctl32.dll
>> version and not the OS version itself. And this is important because the
>> applications without a manifest use comctl32.dll v5.82 even under Windows
>> 10 (not sure about 11, but I suspect it's the case even there), i.e. we
>> still need to keep a lot of code just in case wxMSW is used without a
>> manifest including "Microsoft.Windows.Common-Controls version=6.0.0.0"
>> assembly as a dependency.
>>
>> It would be really nice to not have to deal with these checks neither, but
>> I'm afraid that there might be some strange use cases in which manifest is
>> not being used. OTOH it seems stupid to keep this code if nobody actually
>> does this. Could we, perhaps, try showing an error message during the
>> library initialization if it detects that it doesn't use comctl32.dll v6?
>> At least we'd find out pretty quickly if this actually happens in this
>> case. Or does anybody already know for sure that we need to keep support
>> for the old comctl32.dll?
>>
>> Thanks,
>> VZ
>>
--