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.
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.