Some applications subclass the combo box and handle WM_ERASEBKGND themselves, without using WS_CLIPCHILDREN. This causes them to erase over the editbox child. There's no reason to redraw it in this case since the editbox is supposed to cover it, anyway.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=22260 Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com --- dlls/comctl32/combo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/comctl32/combo.c b/dlls/comctl32/combo.c index 4208ff8..4478e4c 100644 --- a/dlls/comctl32/combo.c +++ b/dlls/comctl32/combo.c @@ -1002,7 +1002,7 @@ static void CBDropDown( LPHEADCOMBO lphc ) SWP_NOACTIVATE | SWP_SHOWWINDOW );
- if( !(lphc->wState & CBF_NOREDRAW) ) + if( !(lphc->wState & (CBF_NOREDRAW | CBF_EDIT)) ) RedrawWindow( lphc->self, NULL, 0, RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW | RDW_NOCHILDREN );
Some applications subclass the combo box and handle WM_ERASEBKGND themselves, without using WS_CLIPCHILDREN. This causes them to erase over the editbox child. There's no reason to redraw it in this case since the editbox is supposed to cover it, anyway.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=22260 Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com --- dlls/user32/combo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/user32/combo.c b/dlls/user32/combo.c index 1b53a2d..5eea89a 100644 --- a/dlls/user32/combo.c +++ b/dlls/user32/combo.c @@ -1002,7 +1002,7 @@ static void CBDropDown( LPHEADCOMBO lphc ) SWP_NOACTIVATE | SWP_SHOWWINDOW );
- if( !(lphc->wState & CBF_NOREDRAW) ) + if( !(lphc->wState & (CBF_NOREDRAW | CBF_EDIT)) ) RedrawWindow( lphc->self, NULL, 0, RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW | RDW_NOCHILDREN );
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=101650
Your paranoid android.
=== debiant2 (64 bit WoW report) ===
user32: win.c:10437: Test failed: Expected foreground window 00000000000D0130, got 00000000018700D2 win.c:10439: Test failed: GetActiveWindow() = 0000000000000000 win.c:10439: Test failed: GetFocus() = 0000000000000000 win.c:10440: Test failed: Received WM_ACTIVATEAPP(1), did not expect it. win.c:10441: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:10449: Test failed: Expected foreground window 00000000000D0130, got 0000000000000000 win.c:10451: Test failed: GetActiveWindow() = 0000000000000000 win.c:10451: Test failed: GetFocus() = 0000000000000000 win.c:10459: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
Some applications subclass the combo box and handle WM_ERASEBKGND themselves, without using WS_CLIPCHILDREN. This causes them to erase over the editbox child. There's no reason to redraw it in this case since the editbox is supposed to cover it, anyway.
What you probably want is to remove RDW_NOCHILDREN, so that children get refreshed as well.
On 12/11/2021 18:24, Alexandre Julliard wrote:
Gabriel Ivăncescu gabrielopcode@gmail.com writes:
Some applications subclass the combo box and handle WM_ERASEBKGND themselves, without using WS_CLIPCHILDREN. This causes them to erase over the editbox child. There's no reason to redraw it in this case since the editbox is supposed to cover it, anyway.
What you probably want is to remove RDW_NOCHILDREN, so that children get refreshed as well.
Ah yes indeed it does fix it as well, thanks for the suggestion, I'll resend.