AUI pane becomes huge on DPI change if a partial minimum size is specified (Issue #26557)
taler21
taler21 created an issue (wxWidgets/wxWidgets#26557)For example, if an AUI pane has a minimum width but no minimum height specified, and it has a scroll bar because its content cannot be fully displayed at its current size, the pane becomes huge when the DPI changed.
It seems as if the size of the pane grows to such an extent that its entire content would be visible, even if the size extends far beyond the screen.
I would expect the current size to be retained, merely scaled to the changed DPI.
The issue can also be reproduced in the aui sample with the following changes.
diff -r -u -p a/samples/aui/auidemo.cpp b/samples/aui/auidemo.cpp --- a/samples/aui/auidemo.cpp 2026-06-03 08:31:53.061465300 +0200 +++ b/samples/aui/auidemo.cpp 2026-06-03 08:32:40.014698200 +0200 @@ -1044,7 +1044,7 @@ MyFrame::MyFrame(wxWindow* parent, m_mgr.AddPane(CreateTreeCtrl(), wxAuiPaneInfo(). Name("tree").Caption("Tree Pane"). - Left().Layer(1).Position(1). + Left().Layer(1).Position(1).MinSize(FromDIP(wxSize(200,-1))). CloseButton(true).MaximizeButton(true).MinimizeButton(). IconMin(wxArtProvider::GetBitmapBundle(wxART_CUT, wxART_MENU))); @@ -2573,6 +2573,9 @@ wxTreeCtrl* MyFrame::CreateTreeCtrl() tree->AppendItem(id, "Subitem 3", 1); tree->AppendItem(id, "Subitem 4", 1); tree->AppendItem(id, "Subitem 5", 1); + for (int j = 6; j <= 20; ++j) + tree->AppendItem(id, wxString::Format("Subitem %d", j), 1); + tree->Expand(id); }
Platform and version information
- wxWidgets version you use: master (39c73b4)
- wxWidgets port you use: wxMSW
- OS and its version: Windows 11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26557)I've finally looked at this and it's indeed due to wxTreeCtrl returning a huge best size. So the questions we need to answer are:
- Is it correct to return such size from its
DoGetBestSize()at all or should it be limited to something reasonable? - Why is this huge best size not taken into account for the layout at the initial DPI but is used after it is rescaled?
- Why is the height of the window not limited by the screen size?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26557)The easiest question to answer is (3): we don't restrict the size in wxNonOwnedWindow::HandleDPIChange() and applying this:
diff --git a/src/msw/nonownedwnd.cpp b/src/msw/nonownedwnd.cpp index 88d302b235..19b489394e 100644 --- a/src/msw/nonownedwnd.cpp +++ b/src/msw/nonownedwnd.cpp @@ -318,7 +318,7 @@ bool wxNonOwnedWindow::HandleDPIChange(const wxSize& newDPI, const wxRect& newRe wxRect actualNewRect = newRect; if ( wxSizer* sizer = GetSizer() ) { - const wxSize minSize = ClientToWindowSize(sizer->GetMinSize()); + const wxSize minSize = sizer->ComputeFittingClientSize(this); wxSize diff = minSize - newRect.GetSize(); // We don't want to shrink the window as if the user had increased
helps a bit.
This is still not ideal because we can (and do, on single monitor systems) move the window origin out of the visible space when increasing it to the size we think we need, so maybe we should also ensure that it's on the same display here?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26557)Returning something reasonable from wxTreeCtrlBase::DoGetBestSize(), i.e. answering (1), results in much more reasonable behaviour, so I've created #26604 with them, but this doesn't address (2) and it really bothers me that I don't understand this at all.
I wonder if anybody else has any ideas?
Anyhow, please test the behaviour of your actual application with this PR: does it improve it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26557)I'm still not sure I understand everything correctly, but I think I found the problem which resulted in min size behaving so counterintuitively and it's fixed by the very simple change of the commit above which is now also part of #26604.
I think together these fixes resolve all the issues here, but please let me know if I'm missing something.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
taler21
taler21 left a comment (wxWidgets/wxWidgets#26557)Yes, #26604 fixes the issues. Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.