wxFrame constructor position is not handled correctly for one of my MacOS screens

[whalley]

Describe the bug
Cannot open window correctly on MacOS setup with multiple monitors.

Expected vs observed behaviour
I have an application that restores the application to the previously saved x,y and w,h settings. It saves position on exit and restores on startup.

It restores correctly on two screens but when a restore is attempted on another screen it does not restore at the correct point.

If I force a re-positon after the wxFrame is created it will go to the correct location.

See: moneymanagerex/moneymanagerex#4791 (this also documents an odd behaviour with toolbar margins that you can ignore)

To Reproduce
I have three screens, one on laptop and two external with locations and dimensions below reported by

this->GetPosition(&value_x, &value_y);
this->GetSize(&value_w, &value_h);

screen 0: x:0, y:25, w:1680, h:969
screen 1: x:-918, y:-1415, w:3440, h:1415
screen 2: x:-3478, y:-1415, w:2560, h:1415

If I edit the samples/aui demo and change to below:

bool MyApp::OnInit()
{
    if ( !wxApp::OnInit() )
        return false;

    wxFrame* frame = new MyFrame(NULL,
                                 wxID_ANY,
                                 "wxAUI Sample Application",
                                 wxPoint(-3090, -940),
                                 wxWindow::FromDIP(wxSize(800, 600), NULL));
    wxLogDebug("frame position: %d, %d", frame->GetPosition().x, frame->GetPosition().y);
    frame->SetPosition(wxPoint(-3090, -940));
    wxLogDebug("frame position: %d, %d", frame->GetPosition().x, frame->GetPosition().y);
    frame->Show();

    return true;
}

The output is:

01:04:41: Debug: frame position: 270, -108
01:04:41: Debug: frame position: -3090, -940

As can be seen the initial wxFrame is not positioned correctly.

Platform and version information

• wxWidgets version you use: v3.2.0-rc1
• wxWidgets port you use: wxOSX
• MacOS: 12.4

[vadz]

Sorry, I have no idea what to do about this, I don't even have a multi-monitor Mac system to check this with. Could you please check what happens inside wxNonOwnedWindowCocoaImpl::Create(), i.e. what do we pass to initWithContentRect:styleMask:backing:defer: there?

@csomor It seems a bit weird to me that the code for setting the initial frame position (in the function above) is different from the code used to set it later in wxNonOwnedWindowCocoaImpl::MoveWindow(), perhaps we should also use setFrame:display: here in Create()?

[csomor]

for creating we are using a preferred initializer, if the problem really is isolated in this method, then indeed we should call a setFrame immediately afterwards, but I'm looking at the behavior with negative offsets on a single screen with the minimal sample, perhaps this already shows some trace ...

[csomor]

ok for reproducing it, you can also use the minimal sample (adding a pos parameter for wxFrame creation) and let it run on a single screen machine, same result, I'll investigate

[csomor]

@whalley could you please test whether this really fixes things for you as well ... thanks

[vadz]

I was wondering if we should be using initWithContentRect:styleMask:backing:defer:screen: instead of just initWithContentRect:styleMask:backing:defer: for the windows not on the main screen, but if it doesn't work even for a single screen case, this really looks like the only thing to do.

I'm reopening this as I think it should be backported to 3.2 too, shouldn't it?

[csomor]

Yes, I don't think we should switch, as it doesn't even work in my case, and yes, we shoud backport, sorry for closing it from the commit message.

[whalley]

@whalley could you please test whether this really fixes things for you as well ... thanks

Just tested, and yes this fixes my issue. Thanks