From 75738bb65b5db3f5d3106e6fad78c7a4a07f993b Mon Sep 17 00:00:00 2001 From: Vadim Zeitlin Date: Mon, 22 Mar 2010 11:40:26 +0000 Subject: [PATCH] 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 --- src/common/sizer.cpp | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/common/sizer.cpp b/src/common/sizer.cpp index 872145da95..31f2503850 100644 --- 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 ) {