SetMaxSize not limiting the size of controls in sizer

[Boksha]

It appears the SetMaxSize function might have been broken in 2.9.0. If the function is called for a control in a sizer, the sizer will still resize the control above the set size, regardless of whether it's the only control in the sizer and regardless of whether the sizer is applied to a top level window or a child like wxPanel.

Included should be a patch to samples/minimal that shows the problem (apply from within folder with -p1). If compiled with any 2.8 version (checked for wxGTK and wxMac), the button stops becoming larger when the window is resized to above the max size, which is what I'd expect to happen. If compiled with 2.9.0 (checked for wxGTK and wxMSW), the button will always take up the entire window.

[vadz]

To be honest I had no idea that anybody used SetMaxSize() like this but if you did and it stopped working we should restore this functionality...

[joshtp]

I have been having trouble with this myself so I set about fixing it, though it is my first foray into editing wxWidgets code so please bear with me and let me know if I do anything wrong.

I've modified wxBoxSizer::RecalcSizes() so that after distributing available space to satisfy the minimum sizes of child items, it then distributes the remaining space based on the items' proportion. I first place all shown items with proportion>0 into a wxSizerItemList, named stretchableChildren. Looping through the list and distributing extra space (delta), if one of the items reaches it's max size I remove that item from stretchableChildren and iterate through the list again.

In the worst case scenario the inner loop will be called (N/2)*(N+1), where N is the total number of visible, stretchable children. I've tried this with 50 wxSizeReportCtrl each with a different max size, such that this worst case occurs, and don't notice any performance difference from the current implementation.

[joshtp]

fix for sizer.cpp

[vadz]

Unfortunately the patch doesn't apply to the latest version in svn which was changed a lot (to fix many bugs, although not this one). Could you please try to merge your changes with the svn version and produce an updated patch?

Sorry for not looking at this one before changing svn code but it shouldn't happen again (i.e. this code is unlikely to change much in the near future).

[vadz]

(In #14498) I think the best way to solve this inconsistency would indeed be to set the max vertical size for these controls by default. Unfortunately, currently this wouldn't work because of #11497. But once it's fixed, this should be simple enough to do.

[HighCommander4]

See this thread for relevant details:  http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/76938

[HighCommander4]

Patch to get wxWindowBase::GetBestSize to respect the window's max size

[HighCommander4]

Patch to get wxBoxSizer::RecalcSizes() to respect the max size of a window

[HighCommander4]

Tests for the previous two patches

[VZ]

(In [72343]) Honour window min and max sizes in wxWindow::GetBestSize().

The best size of the window should be at least as large as its min size and
less than its max size. This allows to override the windows own best size
determination with an explicit SetMinSize() or SetMaxSize() call.

See #11497.

[VZ]

(In [72344]) No real changes, just add wxSizerItem::AddBorderToSize() helper.

Factor out this function from GetMinSizeWithBorder() as it will be used for
max size too in a next commit.

See #11497.

[VZ]

(In [72345]) Respect item max sizes in wxBoxSizer.

Don't give more space than the max size, if set, to wxBoxSizer elements.

Closes #11497.

[VZ]

(In [72586]) Fix handling of not fully specified min/max size in wxBoxSizer.

wxSizerItem::AddBorderToSize() added in r72344 (see #11497) didn't work
correctly as it replaced unspecified (i.e. set to -1) components of wxSize
with the small positive values that did take effect, contrary to the
intention.

Fix it to only adjust the actually set component(s) of wxSize.

Closes #14696.