On Tue May 20 14:12:38 2025 +0000, Rémi Bernon wrote:
I guess but I don't see how it's an issue. Might be a bit weird but pretty much the same as `frame == 1 && flags & RDW_NOFRAME`.
`RDW_FRAME` means nothing when `RDW_INVALIDATE` is not set[^1], overloading it is arguably a flag abuse. Meanwhile, there is nothing weird about `frame == 1 && flags & RDW_NOFRAME` since `frame` is just an internal variable does not have such meaning attached.
(That would also break the `RDW_VALIDATE | RDW_FRAME | RDW_NOFRAME`-with-region case, since `RDW_FRAME` is no longer being ignored which results in more flickers in NC area. But that's a weird flag combination and I guess we're not testing for it anyway, so could be a bit theoretical case as long as no apps actually do that.)
If this patch is a must for this serie then I don't have strong objection, but this nevertheless comes as a maintainability issue since now the reader has to keep track of what `RDW_FRAME` means in which context (externally it means nothing, internally it means "validating child window including its frame").
[^1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-redra...