[PATCH] quartz: Clear the WS_CHILD style in WM_CLOSE instead of unparenting it before.
zfigura at codeweavers.com
Mon Mar 16 11:18:15 CDT 2020
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.
More information about the wine-devel