wxComboBox and wxChoice size

[wxtrac]

Issue migrated from trac ticket # 1423

component: wxMSW | priority: normal

2004-01-20 15:38:45: @JulianSmart created the issue

---

As per:

http://lists.wxwindows.org/cgi-bin/ezmlm-cgi? 5:msp:41537

Hi everybody,

while working on a runtime-modified dialog (which is to be initially read from an XML resource, to make it really interesting), I have had several problems with the wxChoice and wxComboBox implementations in wxMSW.

Testing environment: MinGW 3.1.0, wxMSW 2.4.2, WindowsXP/Pro+SP1

1) Creating a wxChoice/wxComboBox instance with a given number of strings and then showing it works correctly. Increasing the number of strings afterwards, however, doesn't. E.g., if you have initally only one string in the list and later add 9 more, the drop- down list still holds only one line (with scroll buttons), which is quite annoying.

2) GetBestSize() gives the height of the underlying MSW widget (which includes the height of the drop-down list) and is therefore consistent with neither the documentation nor with the behavior of the other ports. Therefore, trying to adjust a sizer-controlled window with

wxSize bestSize = choice->GetBestSize(); choice->GetContainingSizer()->SetItemMinSize(choice, bestSize.Width(), bestSize.Height()); window->GetSizer()->SetSizeHints(window); window->Fit();

screws the layout. On wxGTK for example, it works as it should.

Both problems are due to the quite peculiar way the widget calculates its size on wxMSW. Rather than introducing a private function that calculates the needed MSW widget size out of the number of stored strings the implementation misuses GetBestSize() for this purpose, breaking the compatiblity to both documentation and other ports.

Furthermore, Append() apparently does not update the MSW widget size, which I also consider a bug. Interestingly, if you initalize the wxChoice/wxComboBox object with e.g. 10 strings and then do a Clear(), it is rendered correctly (i.e., with only the needed number of lines in the drop-down list). However, this may depend on the behaviour of WindowsXP (on which I test my program) and can therefore be different for other Windows versions. The correct way would be to recalculate the size after Clear(), Append() and Delete () operations.

I have unfortunately neither the time nor the needed intimate knowlege of wxMSW needed to provide a patch, but I would much appreciate if someone could look into it. I have found ways to get reasonable results, but they have 'work-around' written all over them, and of course I do not want to start writing work- arounds for buggy implementations. This would IMHO render the use of a cross-platform toolkit absurd.

Regards, Robert Fendt (Submitted on his behalf by Julian Smart)

[wxtrac]

2004-01-20 15:38:47: @JulianSmart uploaded file minimal.cpp (3.0 KiB)

Modified sample to show bug

[wxtrac]

2004-01-20 15:45:57: @JulianSmart commented

---

Certainly I think DoGetBestSize should return an approximation like

EDIT_HEIGHT_FROM_CHAR_HEIGHT(cy);

as per wxTextCtrl::DoGetBestSize. We can also recompute the list size as you say. However I'm puzzled why the combobox list stays at the initial height in your example code, while the choice list is the full height for 5 items. After all they're implemented with the same underlying control. (This is tested against CVS head, 2004-01-20). Ah, it's probably the inclusion of CBS_AUTOHSCROLL in wxComboBox and not in wxChoice.

[wxtrac]

2004-02-07 19:40:09: @vadz commented

---

All of these problems (and more) should be fixed in cvs HEAD, please test.

Thanks!