Don't enter an infinite loop if a spacer with min size of -1 is used.

Sizer layout algorithm broke down if min size of an item happened to be -1,
i.e. the same value as we use as a sentinel for indicating that the min size
hasn't been fixed yet. It doesn't make much sense for min size to be negative
in the first place but currently this can happen at least for spacers so deal
with it here by ensuring that the min size we use is positive.

Closes #11842.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63735 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

diff --git a/src/common/sizer.cpp b/src/common/sizer.cpp
index 872145da95d120f3fbaa1c743f369e4c38b93320..31f25038500cd3385d5d1f6ceabb0ff140163e8a 100644 (file)
--- a/src/common/sizer.cpp
+++ b/src/common/sizer.cpp
@@ -2171,8 +2171,19 @@ void wxBoxSizer::RecalcSizes()
             if ( majorSizes[n] != wxDefaultCoord )
                 continue;
 
-            const wxCoord
-                minMajor = GetSizeInMajorDir(item->GetMinSizeWithBorder());
+            wxCoord minMajor = GetSizeInMajorDir(item->GetMinSizeWithBorder());
+
+            // it doesn't make sense for min size to be negative but right now
+            // it's possible to create e.g. a spacer with (-1, 10) as size and
+            // people do it in their code apparently (see #11842) so ensure
+            // that we don't use this -1 as real min size as it conflicts with
+            // the meaning we use for it here and negative min sizes just don't
+            // make sense anyhow (which is why it might be a better idea to
+            // deal with them at wxSizerItem level in the future but for now
+            // this is the minimal fix for the bug)
+            if ( minMajor < 0 )
+                minMajor = 0;
+
             const int propItem = item->GetProportion();
             if ( propItem )
             {