[PATCH] comctl32: Add partial support for LVM_SETBKIMAGE.

Zhiyi Zhang zzhang at codeweavers.com
Fri Jun 10 04:16:15 CDT 2022



On 6/10/22 17:08, Dmitry Timoshkov wrote:
> Zhiyi Zhang <zzhang at codeweavers.com> wrote:
>
>>>> Also, I found LVM_SETBKIMAGE is acting a bit weird on Windows. For example,
>>>> if a LVM_SETBKIMAGE message trying to set a bitmap
>>>> is sent the second time. The second message returns FALSE and the background
>>>> image gets reset to none(from LVM_GETBKIMAGE). I don't know if we should
>>>> implement such a behavior but I would be more comfortable with some tests.
>>> According to my testing LVM_SETBKIMAGE always returns 0.
>> If LVM_SETBKIMAGE for a bitmap succeeds, it does return TRUE.
> Where do you see this? In my tests LVM_SETBKIMAGE always returns 0:
> https://testbot.winehq.org/JobDetails.pl?Key=116659

You're only testing with comctl32 v5. Please see https://testbot.winehq.org/JobDetails.pl?Key=116666&f204=exe32.report#k204


>>>  Regarding calling
>>> LVM_SETBKIMAGE again with the same hbitmap I'd guess that the control first
>>> destroys previosuly assigned bitmap, and that leads to a being assigned bitmap
>>> gets destroyed. The conrol then probably verifies bitmap validity before saving
>>> it internally, and that would explain why LVM_GETBKIMAGE returns 0.
>>>
>> Right, this make sense. It would be nice to add a test for this. MSDN doesn't mention that the bitmap
>> will be managed by the control after the message.
> I just added a test that calls LVM_SETBKIMAGE twice with the same bitmap,
> and calls GetObject() to verify the bitmap validity after each call. Adding
> the tests with LVM_GETBKIMAGE would required implementing it, and this deserves
> a separate patch, probably with another set of tests.
>




More information about the wine-devel mailing list