[PATCH resend 1/2] comctl32: Don't redraw the Combo Box when dropped down if it has an editbox.

[Gabriel Ivăncescu]

On 18/07/2020 19:17, Nikolay Sivov wrote:
> 
> 
> On 7/17/20 3:46 PM, Gabriel Ivăncescu wrote:
>> Hi Nikolay,
>>
>> On 17/07/2020 10:56, Nikolay Sivov wrote:
>>> On 7/15/20 4:21 PM, Gabriel Ivăncescu wrote:
>>>> 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
>>> Have you tried to replicate this with standalone test program, since
>>> Total Commander is wine-aware?
>>>
>>
>> Yeah, the bug report has a small test app at the end that exhibits the
>> behavior (just compile it with MinGW). Or did you mean something else?
> 
> Thanks. On Windows first combo, the one on top, does not show dropdown
> at all. Button is responsive but does not do anything it seems. Is is
> the one that was supposed to show the issue?
>>
>> Thanks,
>> Gabriel
> 

The dropdown itself is unimportant. What matters is the text in the edit 
box of the first combo box. Look at the edit box with "test". When you 
click on the drop down, the area with the edit box becomes black (or 
rather, COLOR_WINDOWTEXT) on Wine, but not on Windows.

Of course, that's because the app does that on purpose in 
WM_ERASEBKGND—which simulates the problem and what Total Commander 
actually does (except it paints it grey).

Since the edit box covers the combo box anyway, the patch just doesn't 
redraw it in this case, which fixes the problem.