Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Parent of owned child window not visible #2060

Closed
Tracked by #2043
msiglreith opened this issue Nov 11, 2021 · 6 comments · Fixed by #2062
Closed
Tracked by #2043

Windows: Parent of owned child window not visible #2060

msiglreith opened this issue Nov 11, 2021 · 6 comments · Fixed by #2062
Assignees
Labels
B - bug Dang, that shouldn't have happened DS - windows P - high Vital to have

Comments

@msiglreith
Copy link
Member

msiglreith commented Nov 11, 2021

Declaring one windows as owner will make the owner window invisible which is unintentional and a regression from 0.25.
Seems to be caused by #1933

Minimum example:

fn main() -> anyhow::Result<()> {
    let event_loop = EventLoop::new();

    let owner = WindowBuilder::new()
        .with_title("owner")
        .build(&event_loop)
        .unwrap();

    let child = WindowBuilder::new()
        .with_title("child")
        .with_owner_window(owner.hwnd() as _)
        .build(&event_loop)
        .unwrap();

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;
    })
}
@msiglreith msiglreith added B - bug Dang, that shouldn't have happened DS - windows P - high Vital to have labels Nov 11, 2021
@msiglreith msiglreith mentioned this issue Nov 11, 2021
9 tasks
@msiglreith
Copy link
Member Author

hm looks like only the child window receives a WM_PAINT event

@msiglreith
Copy link
Member Author

msiglreith commented Nov 12, 2021

Not passing the parent HWND on window creation for owned windows (which is optional anyway for popups) seems to alleviate the issue and show the parent window correctly - doing the initialization in WM_CREATE instead of WM_NCCREATE as well but that would defeat the purpose of #1933
Unsure what's the underlying issue tho

@maroider
Copy link
Member

If I've understood the issue correctly, it seems you've run into what Raymond Chen describes here. That is, a window can optionally have a parent XOR an owner.

@msiglreith
Copy link
Member Author

@maroider sorry, forget that part - not setting the handle delete the ownership which isn't the goal either 😓

@maroider
Copy link
Member

maroider commented Nov 13, 2021

I think there were only a couple of things that absolutely had to happen in response to WM_NCCREATE rather than WM_CREATE, like a call to EnableNonClientDpiScaling (which strictly speaking doesn't require our window state to be initialized). We don't currently dispatch any events in response to WM_NCCREATE and WM_CREATE, so it should be feasible to move most of the initialization logic into WM_CREATE (with some care).

(I should probably try to reproduce this bug, TBH, but I no longer have Windows installed on my main machine)

@maroider
Copy link
Member

I finally have a Windows 10 VM I can test with, and I managed to reproduce the bug.
Strangely enough, the owner window still appears when I hover over the preview in the taskbar.
I'll get you a review for #2062 shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened DS - windows P - high Vital to have
Development

Successfully merging a pull request may close this issue.

2 participants