On 3/16/20 11:12 AM, Gabriel Ivăncescu wrote:
On 16/03/2020 18:00, Zebediah Figura wrote:
On 3/16/20 7:52 AM, Gabriel Ivăncescu wrote:
We handle it in WM_CLOSE to match Windows more closely, in case the window belongs to a different thread.
What's the point of doing this?
Well, based on message sequence I've been investigating, I'm somewhat sure Windows does it when handling a custom message. I know that's internal implementation details, but I figured if we make it closer to Windows by just clearing the style anyway, at least it would be worth it to avoid surprises in the future by also mimicking that behavior.
I can drop it, of course, and just handle it like where it was originally. Should I?
I don't see a reason to emulate Windows just for the sake of emulating Windows, in a situation like this where the placement doesn't particularly matter. So yeah, I'd prefer this code left where it is, until we get a good reason to change it.
While you're at it, you could add a test to show that the parent shouldn't lose focus, by calling e.g. SetActiveWindow() in test_window_threading(), before releasing the filter.