On Tue Oct 8 14:31:02 2024 +0000, Zhiyi Zhang wrote:
The problem is that I don't know exact placement of sibling windows
that get corrupted. As I mentioned I'm using winecfg (where this bug was noticed originally), and replicating what winecfg doesn't seem reasonable. Why not use winecfg as an interactive test to check the correctness of listview repainting? Because interactive tests are often not run. Besides, this is not something that can't be tested without human interaction.
and replicating what winecfg doesn't seem reasonable.
Having a test replicating the behavior that can reproduce the bug seems reasonable to me.
Besides, the patch fixes an obvious bug, user32 painting mechanisms
are unversal and comctl32 controls are just normal user32 windows that must follow the user32 painting rules. So, I don't get where the speculation about comctl32 strange behaviour comes from. It might seem obvious and it's probably fine to commit this MR. But I would feel more comfortable approving this MR with a test.
Could you show two screenshots comparing the corrupted window area of winecfg before and after this MR?