bug fix for some weird combobox behaviour

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

src/msw/combobox.cpp

@@ -477,6 +477,19 @@ void wxComboBox::SetSelection(long from, long to)
 
 void wxComboBox::DoMoveWindow(int x, int y, int width, int height)
 {
+    // here is why this is necessary: if the width is negative, the combobox
+    // window proc makes the window of the size width*height instead of
+    // interpreting height in the usual manner (meaning the height of the drop
+    // down list - usually the height specified in the call to MoveWindow()
+    // will not change the height of combo box per se)
+    //
+    // this behaviour is not documented anywhere, but this is just how it is
+    // here (NT 4.4) and, anyhow, the check shouldn't hurt - however without
+    // the check, constraints/sizers using combos may break the height
+    // constraint will have not at all the same value as expected
+    if ( width < 0 )
+        return;
+
     int cx, cy;
     wxGetCharSize(GetHWND(), &cx, &cy, &GetFont());
 
@@ -484,12 +497,10 @@ void wxComboBox::DoMoveWindow(int x, int y, int width, int height)
     // default and also 10 items max (if we always use n, the list will never
     // have vertical scrollbar)
     int n = GetCount();
-    if ( !n )
+    if ( !n || (n > 10) )
-        n = 10;
-    else if ( n > 10 )
         n = 10;
 
-    height = n * EDIT_HEIGHT_FROM_CHAR_HEIGHT(cy);
+    height = (n + 1)* EDIT_HEIGHT_FROM_CHAR_HEIGHT(cy);
 
     wxControl::DoMoveWindow(x, y, width, height);
 }