If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
If I may add to the confusion... recently we stumbled upon a similar problem. My application likes to store its position and size in an xml file when closing the application. So I can restart the application restoring the same location and size when you last left the application. That works fine, when I maximize the applications main window (MDI application) it works fine too. But when I restart the application the size of the window is too big, some 15 pixels (lines) of the bottom are now obscured behind the taskbar. Re-applying the maximize button, restores all back to normal.
So something's off somehow in reporting the size of a window when maximized. Now I stumbled upon the fact that when you right click on the taskbar (Win10 pro) and you uncheck the 'lock all taskbars' feature, the problem disappears and all works fine. So either this is a bug in windows or somewhere in wxWidgets (somewhere deep I assume).
Regardless of if there's a bug somewhere, you shouldn't store the maximized size of a window. You should only store the un-maximized size and a "maximized" flag separately. Otherwise the you (and the user) lose the information of the unmaximized size (the size the window gets when the user un-maximized it).
bool TheApp::OnInit()
{
wxFrame * main_frame = new wxFrame(nullptr, wxID_ANY, L"TheApp", wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE | wxMAXIMIZE);
main_frame->Centre(wxBOTH); // this line causes the problem
main_frame->Show();
return true;
}
You don't need to (shouldn't ?) call Centre() on a maximized window. I'm guessing something in the Center() code is confused when it tries to compute the offsets to center a maximized window.
Okay, I figured out the problem, that might be the same as the OP's.
I noticed when testing that the window for split second would sometimes be maximized (depending on timing) but then get kicked out.
What is required is inside any window sizing events you have to test IsMaximized and change the behavior to not do anything, because changing the size kicks it out of maximized state. In hindsight it seems obvious, but you wouldn't think of it. Both cases where my events change the size from inside the sizing events were hacks to workaround other quirks.