Signed-off-by: Dmitry Timoshkov dmitry@baikal.ru --- dlls/comctl32/listview.c | 65 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c index 730bf4aaddd..3ca76c2ef05 100644 --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -91,7 +91,7 @@ * * Messages: * -- LVM_ENABLEGROUPVIEW - * -- LVM_GETBKIMAGE, LVM_SETBKIMAGE + * -- LVM_GETBKIMAGE * -- LVM_GETGROUPINFO, LVM_SETGROUPINFO * -- LVM_GETGROUPMETRICS, LVM_SETGROUPMETRICS * -- LVM_GETINSERTMARK, LVM_SETINSERTMARK @@ -297,6 +297,7 @@ typedef struct tagLISTVIEW_INFO COLORREF clrBk; COLORREF clrText; COLORREF clrTextBk; + HBITMAP hBkBitmap;
/* font */ HFONT hDefaultFont; @@ -4567,11 +4568,30 @@ static INT LISTVIEW_GetTopIndex(const LISTVIEW_INFO *infoPtr) */ static inline BOOL LISTVIEW_FillBkgnd(const LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) { - if (!infoPtr->hBkBrush) return FALSE; + if (infoPtr->hBkBitmap) + { + HDC hdc_src = CreateCompatibleDC(hdc); + + TRACE("(hdc=%p, lprcBox=%s, hBkBitmap=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBitmap); + + SelectObject(hdc_src, infoPtr->hBkBitmap); + BitBlt(hdc, lprcBox->left, lprcBox->top, + lprcBox->right - lprcBox->left, + lprcBox->bottom - lprcBox->top, + hdc_src, lprcBox->left, lprcBox->top, SRCCOPY); + + DeleteDC(hdc_src);
- TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush); + return TRUE; + } + else if (infoPtr->hBkBrush) + { + TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush);
- return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + } + + return FALSE; }
/* Draw main item or subitem */ @@ -8028,7 +8048,37 @@ static BOOL LISTVIEW_SetBkColor(LISTVIEW_INFO *infoPtr, COLORREF color) return TRUE; }
-/* LISTVIEW_SetBkImage */ +static BOOL LISTVIEW_SetBkImage(LISTVIEW_INFO *infoPtr, const LVBKIMAGEW *image, BOOL isW) +{ + TRACE("%08lx,%p,%p,%u,%d,%d\n", image->ulFlags, image->hbm, image->pszImage, + image->cchImageMax, image->xOffsetPercent, image->yOffsetPercent); + + if (image->ulFlags & ~LVBKIF_SOURCE_MASK) + FIXME("not supported flags %08lx\n", image->ulFlags & ~LVBKIF_SOURCE_MASK); + + if (image->xOffsetPercent || image->yOffsetPercent) + FIXME("not supported offset %d,%d\n", image->xOffsetPercent, image->yOffsetPercent); + + switch (image->ulFlags & LVBKIF_SOURCE_MASK) + { + case LVBKIF_SOURCE_NONE: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = 0; + return TRUE; + + case LVBKIF_SOURCE_HBITMAP: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = image->hbm; + InvalidateRect(infoPtr->hwndSelf, NULL, TRUE); + return TRUE; + + case LVBKIF_SOURCE_URL: + FIXME("LVBKIF_SOURCE_URL: %s\n", isW ? debugstr_w(image->pszImage) : debugstr_a((LPCSTR)image->pszImage)); + break; + } + + return FALSE; +}
/*** Helper for {Insert,Set}ColumnT *only* */ static void column_fill_hditem(const LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, @@ -10406,6 +10456,7 @@ static LRESULT LISTVIEW_NCDestroy(LISTVIEW_INFO *infoPtr) infoPtr->hFont = 0; if (infoPtr->hDefaultFont) DeleteObject(infoPtr->hDefaultFont); if (infoPtr->clrBk != CLR_NONE) DeleteObject(infoPtr->hBkBrush); + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap);
SetWindowLongPtrW(infoPtr->hwndSelf, 0, 0);
@@ -11554,7 +11605,9 @@ LISTVIEW_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) case LVM_SETBKCOLOR: return LISTVIEW_SetBkColor(infoPtr, (COLORREF)lParam);
- /* case LVM_SETBKIMAGE: */ + case LVM_SETBKIMAGEA: + case LVM_SETBKIMAGEW: + return LISTVIEW_SetBkImage(infoPtr, (LVBKIMAGEW *)lParam, uMsg == LVM_SETBKIMAGEW);
case LVM_SETCALLBACKMASK: infoPtr->uCallbackMask = (UINT)wParam;
Let's use "comctl32/listview: Add partial support for LVM_SETBKIMAGE." for the subject.
On 4/22/22 21:29, Dmitry Timoshkov wrote:
Signed-off-by: Dmitry Timoshkov dmitry@baikal.ru
dlls/comctl32/listview.c | 65 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c index 730bf4aaddd..3ca76c2ef05 100644 --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -91,7 +91,7 @@
- Messages:
- -- LVM_ENABLEGROUPVIEW
- -- LVM_GETBKIMAGE, LVM_SETBKIMAGE
- -- LVM_GETBKIMAGE
- -- LVM_GETGROUPINFO, LVM_SETGROUPINFO
- -- LVM_GETGROUPMETRICS, LVM_SETGROUPMETRICS
- -- LVM_GETINSERTMARK, LVM_SETINSERTMARK
@@ -297,6 +297,7 @@ typedef struct tagLISTVIEW_INFO COLORREF clrBk; COLORREF clrText; COLORREF clrTextBk;
HBITMAP hBkBitmap;
/* font */ HFONT hDefaultFont;
@@ -4567,11 +4568,30 @@ static INT LISTVIEW_GetTopIndex(const LISTVIEW_INFO *infoPtr) */ static inline BOOL LISTVIEW_FillBkgnd(const LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) {
Let's remove inline.
- if (!infoPtr->hBkBrush) return FALSE;
- if (infoPtr->hBkBitmap)
- {
HDC hdc_src = CreateCompatibleDC(hdc);TRACE("(hdc=%p, lprcBox=%s, hBkBitmap=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBitmap);SelectObject(hdc_src, infoPtr->hBkBitmap);BitBlt(hdc, lprcBox->left, lprcBox->top,lprcBox->right - lprcBox->left,lprcBox->bottom - lprcBox->top,hdc_src, lprcBox->left, lprcBox->top, SRCCOPY);
A bit of inconsistent styling. Let's wrap the parameters for BitBlt() at 100 characters.
DeleteDC(hdc_src);
- TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush);
return TRUE;- }
This is not an either or relation. The background brush is used to fill background if present. Then the background image is painted on top of that if present.
- else if (infoPtr->hBkBrush)
- {
TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush);
- return FillRect(hdc, lprcBox, infoPtr->hBkBrush);
return FillRect(hdc, lprcBox, infoPtr->hBkBrush);- }
- return FALSE;
}
/* Draw main item or subitem */ @@ -8028,7 +8048,37 @@ static BOOL LISTVIEW_SetBkColor(LISTVIEW_INFO *infoPtr, COLORREF color) return TRUE; }
-/* LISTVIEW_SetBkImage */ +static BOOL LISTVIEW_SetBkImage(LISTVIEW_INFO *infoPtr, const LVBKIMAGEW *image, BOOL isW) +{
- TRACE("%08lx,%p,%p,%u,%d,%d\n", image->ulFlags, image->hbm, image->pszImage,
image->cchImageMax, image->xOffsetPercent, image->yOffsetPercent);
Add a space after comma.
- if (image->ulFlags & ~LVBKIF_SOURCE_MASK)
FIXME("not supported flags %08lx\n", image->ulFlags & ~LVBKIF_SOURCE_MASK);- if (image->xOffsetPercent || image->yOffsetPercent)
FIXME("not supported offset %d,%d\n", image->xOffsetPercent, image->yOffsetPercent);- switch (image->ulFlags & LVBKIF_SOURCE_MASK)
- {
- case LVBKIF_SOURCE_NONE:
if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap);infoPtr->hBkBitmap = 0;return TRUE;
This is supposed to return FALSE.
- case LVBKIF_SOURCE_HBITMAP:
if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap);infoPtr->hBkBitmap = image->hbm;InvalidateRect(infoPtr->hwndSelf, NULL, TRUE);
I don't think the InvalidateRect() is needed.
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.
return TRUE;- case LVBKIF_SOURCE_URL:
FIXME("LVBKIF_SOURCE_URL: %s\n", isW ? debugstr_w(image->pszImage) : debugstr_a((LPCSTR)image->pszImage));break;- }
- return FALSE;
+}
/*** Helper for {Insert,Set}ColumnT *only* */ static void column_fill_hditem(const LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, @@ -10406,6 +10456,7 @@ static LRESULT LISTVIEW_NCDestroy(LISTVIEW_INFO *infoPtr) infoPtr->hFont = 0; if (infoPtr->hDefaultFont) DeleteObject(infoPtr->hDefaultFont); if (infoPtr->clrBk != CLR_NONE) DeleteObject(infoPtr->hBkBrush);
if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap);
SetWindowLongPtrW(infoPtr->hwndSelf, 0, 0);
@@ -11554,7 +11605,9 @@ LISTVIEW_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) case LVM_SETBKCOLOR: return LISTVIEW_SetBkColor(infoPtr, (COLORREF)lParam);
- /* case LVM_SETBKIMAGE: */
case LVM_SETBKIMAGEA:
case LVM_SETBKIMAGEW:
return LISTVIEW_SetBkImage(infoPtr, (LVBKIMAGEW *)lParam, uMsg == LVM_SETBKIMAGEW);
case LVM_SETCALLBACKMASK: infoPtr->uCallbackMask = (UINT)wParam;
Zhiyi Zhang zzhang@codeweavers.com wrote:
Thanks for the review.
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. 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.
On 6/10/22 16:42, Dmitry Timoshkov wrote:
Zhiyi Zhang zzhang@codeweavers.com wrote:
Thanks for the review.
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.
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.
Thanks, Zhiyi
Zhiyi Zhang zzhang@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
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.
On 6/10/22 17:08, Dmitry Timoshkov wrote:
Zhiyi Zhang zzhang@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#k2...
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.
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
On 6/10/22 17:22, Dmitry Timoshkov wrote:
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
I don't think that explains destroying the bitmap on the 2nd call. It looks like v5 really supports LVM_SETBKIMAGE, and the only difference in v6 is the return value.
Dmitry Timoshkov dmitry@baikal.ru wrote:
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
I don't think that explains destroying the bitmap on the 2nd call. It looks like v5 really supports LVM_SETBKIMAGE, and the only difference in v6 is the return value.
Is there anything else that should be addressed in this patch?
On 6/15/22 15:05, Dmitry Timoshkov wrote:
Dmitry Timoshkov dmitry@baikal.ru wrote:
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
I don't think that explains destroying the bitmap on the 2nd call. It looks like v5 really supports LVM_SETBKIMAGE, and the only difference in v6 is the return value.
Is there anything else that should be addressed in this patch?
I see. No. I sent a v4 https://source.winehq.org/patches/data/238807.
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
I don't think that explains destroying the bitmap on the 2nd call. It looks like v5 really supports LVM_SETBKIMAGE, and the only difference in v6 is the return value.
Is there anything else that should be addressed in this patch?
I see. No. I sent a v4 https://source.winehq.org/patches/data/238807.
Thanks!
Zhiyi Zhang zzhang@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#k2...
Thanks. Do you think it's really necessary to change return value for the v6 case?
Yes, I think it's necessary. I don't think comctl32 v5 support LVM_SETBKIMAGE at all. The FALSE is probably from DefWindowProc().
I don't think that explains destroying the bitmap on the 2nd call. It looks like v5 really supports LVM_SETBKIMAGE, and the only difference in v6 is the return value.
Is there anything else that should be addressed in this patch?
I see. No. I sent a v4 https://source.winehq.org/patches/data/238807.
The patch seems to be ignored, could you please take care of it?
Thanks.
-
Dmitry Timoshkov -
Zhiyi Zhang