Why does the size of a combo box include the size of the drop-down?


Many people are surprised to discover that when you create a combo box (either in code via CreateWindow or indirectly via a dialog box template), the size you specify describes the size of the combo box including the drop-down list box, even though the drop-down list box is not visible on the screen. For example, if you say that you want the combo box to be 200 pixels tall, it will be visible on the screen as a 20-pixel-tall (say) edit control, and when the user drops the list box by clicking on the drop-down arrow, the list box will be 180 pixels tall. This has the unfortunate consequence that if you fail to take this into account and specify in your dialog box template that you wanted a 20-pixel-tall combo box, you will end up with a combo box whose drop-down listbox is zero pixels tall! That's not a very useful combo box. Those who have switched to version 6 of the common controls library may have noticed that the version 6 combo box detects this common mistake and "auto-repairs" it: It recognizes that the height passed by the creator of the combo box is absurdly small and automatically enlarges it to something more reasonable. This was done at the request of the user interface designers who were fed up with struggling with program after program that set their combo box heights too small and ended up showing uselessly-small combo box drop-down list boxes. Imagine, for example, a "Choose your state" combo box where the drop-down shows only two states at a time! (The change was not made to pre-version 6 combo boxes for compatibility reasons.)

But I still haven't answered the question, "Why does the size of a combo box include the size of the drop-down?" The reason is that the original combo box did not have a drop-down. Originally, a combo box was just an edit control and a list box glued together. (You can still see this "old-timey-style combo box" in Notepad's Font dialog.) You can think of the original combo box as a modern combo box where the drop-down was pinned open. Under this original design, it was reasonable for the size of the combo box to include both the edit control and the list box, since that's how much space it took up.

When the "drop-down" style of combo box was invented, the designers wanted to make the transition from "old-timey combo box" to "slick new drop-down combo box" as easy as possible, so the sizing behavior was retained so that code and dialog boxes wouldn't have to change to take advantage of the new drop-down style combo box aside from changing to the CBS_DROPDOWN or CBS_DROPDOWNLIST style in the parameters to CreateWindow or in the dialog template.

And that's why the size of a combo box includes the size of the drop-down. It's a chain of backwards compatibility going all the way back to the old-timey days before combo boxes learned how to drop down.

Comments (21)
  1. Steven says:

    This has bit me quite often, but the other way around. I’ve often tried to figure out how to set the size of just the edit control part of the combobox. Is that even possible?

  2. Serge Wautier says:

    I was bitten too. It was a vicious one!

    appTranslator (my localization product) features a translation-oriented dialog editor to display the dialogs of your exe (to let you translate them). It also let you move and resize controls to accomodate enlarged texts (due to translation). That’s were it hurts: When you move a combobox, appTranslator records the new size and pos of the combo, which is not the one you expect in your dialog template. After some time, people started to complain that some combos didn’t drop down anymore. But we couldn’t simulate it. Until I realized the problem only occurs on Win2000 (which actually means ‘doesn’t happen on XP).

    So I was bitten by the size convention trick AND by the XP ‘auto-fix’ (because it hides the problem) :-(

    I’m glad this is old history by now!

  3. Chris Becke says:

    er, use a smaller dialog font?

  4. AnotherMatt says:

    I think the whole idea of setting the size of the drop down list was dumb to begin with.  Why not just make it go to the bottom of the screen every time?  It’s a popup.  I was make my drop-down lists as large as possible.  As any woman will tell you, size does matter.  The Windows desktop is like a big, gaping…er, nevermind.

  5. Daitarn says:

    > I was make my drop-down lists as large as possible.

    I don’t find full-screen dropdowns very usable. Open IE (or firefox or whatever browser). Click on the URL dropdown and think about how crappy it would be to find your URL if you had it full screen on an 30" LCD turned in portrait mode..

  6. Jay B says:

    In response to Serge Wautier’s post:

    You would think these subtle changes with big impact would somehow make it into the hands of developers.

    Maybe I’ve missed it all this time, but does Microsoft publish some kind of Developer-targetted Release Notes for each OS revision?  I don’t recall ever hearing about XP doing an "auto-repair" on combo boxes.

  7. Jay B says:

    In response to Serge Wautier’s post:

    You would think these subtle changes with big impact would somehow make it into the hands of developers.

    Maybe I’ve missed it all this time, but does Microsoft publish some kind of Developer-targetted Release Notes for each OS revision?  I don’t recall ever hearing about XP doing an "auto-repair" on combo boxes.

  8. Mihai says:

    <<You can still see this "old-timey-style combo box" in Notepad’s Font dialog>>

    That is in fact the standard font selection dialog (displayed by ChooseFont).

    But if we talk about archaic looking stuff, what do you think about the "Add Fonts" dialog? (Control Panel -> Fonts, then File -> Install New Font…). Any chances to see that improved?

  9. Mihai says:

    On the combo-box size: the thing that bothers me is that the VS resource editor handles it very badly.

    If you add the combo-box just by clicking on the dialog, the vertical size is 22. All controls (buttons and such) get a reasonable size.

    If you click and drag, you cannot drag outside the dialog, meaning that combos at the bottom of the dialog will be very short.

    This is only half of the problem. Once you add a combo-box (with click, or click-and-drag), there is no way to make it taller. Ever.

    So, you have to get it right to begin with, delete it and add it again, or go to Notepad!

  10. KiwiBlue says:

    This is only half of the problem. Once

    > you add a combo-box (with click, or

    > click-and-drag), there is no way to

    > make it taller. Ever.

    Clicking on dropdown arrow doesn’t work for you?

  11. Reinder says:

    I find it hard to believe this explanation.

    When you convert that font selection dialog to use the new-style combo-box, you will hopefully notice some freshly vacated screen real estate. To fill that up, you will have to redesign your dialog, and possibly even your entire application (hey, we can merge two dialogs. No, better yet: we can move this dialog into our main window!)

    Relative to that, the amount of work to specify the desired heights of both the collapsed and the expanded combo box is so minute that I do not see how it could have any influence on this design decision.

  12. Tom Seddon says:

    Steven: you can use the GetComboBoxInfo function to get HWNDs for the combo components. I guess if you do a UnionRect on the RECTs of its components, you’ll get the dimensions of the whole thing.

    (Probably. I’ve only ever used this function to see if the current focus HWND is part of a combo box, as part of some WM_NEXTDLGCTL processing.)

  13. Tom Seddon says:

    Reinder — I bet part of the problem is that people don’t know you can click on the down arrow in the dialog editor. It took me, certainly, a while to work this out.

    Draw the obvious conclusion, if you like! But Mihai’s post implies this is a common problem. And indeed, I’ve seen a number of programs that exhibit the same flaw. (And when the solution is pointed out, the response is usually "hey… cool! I never knew that" :)

  14. Leif says:

    There’s a fine line between doing things in the name of "backwards compatibility" and doing things in the name of "lazyiness".  Given that, in this case, they had a new CBS_XXX code to distinguish between new and old, I’d file this under the "lazyiness" heading… it is another instance of, "let’s make this new thing an easy permutation of what came before, so that we don’t have to edit too much code."

    Assuming Raymond’s explaination is accurate, of course.  As Reinder points out, it doesn’t make perfect sense.  I’d guess it was either an accident, or a misguided desire to give designers control over the drop-down size.

  15. 8 says:

    "er, use a smaller dialog font?"

    Smaller then the default?

    …*places shortcut to magnifyer on the desktop*

  16. This story doesn’t sound right to me. I distinctly remember all three types of combo boxes coming out at the same time.

    I could be mistaken, but it’s a pretty strong memory.

  17. uniware says:

    I and others are bite by this feature years before. As beginners, we were confused and couldn’t figure out what was wrong.

  18. Igor Delovski says:

    Looks to me as if Microsoft is not using these combo boxes in any of their products – Notepad does not qualify. Products like Office and even dev tools like .Net framework or even Fox database.

    Are they all CBS_OWNERDRAW[FIXED]?

    But these are poorly documented and maybe Raymond can give us another article about combos?

  19. Stu says:

    Looking at the screenshots here:

    http://www.toastytech.com/guis

    No form of combo box appears before Windows 3.0, when the "new" type is already preasent.

    Even if the "old" type was preasent in Windows 2.0 and just isn’t in any of those screenshots, the number of applications available for Windows 2.0 can be counted on your fingers.

    As changing to the "new" type of combo box would entail a redesign of the dialog anyway (as Rainder pointed out) and the amount of applications affected was so tiny, the reasons behind this "design decision" seem void.

    Therefore, it seems to me that the only "real" reason for this is that the "new" combo box was developed using the tried-and-tested technique of copy-and-paste code reuse.

  20. John Elliott says:

    In a Windows 3.0 installation, the word ‘combo’ appears in several files:

    % grep –recursive -l -i combo *

    sysini2.txt

    system/user.exe

    system/win386.exe

    vbrun100.dll

    but the same command in a Windows 2.0 or 1.0 WINDOWS directory finds nothing.

  21. Ensizer says:

    As others has pointed out, raymond’s reason isn’t valid. The real reason why the given height affects the dropped down list and not the editbox is easily understood with some simple logic and imagination how it would be otherwise. At the creation only one height can be set. The control must be usable without any extra calls (to SendMessage). It’s more meaningful to give the editbox part a defaultheight than the dropped down list.

    This is probably also the reason why the editbox’s height is r/o.

Comments are closed.

Skip to main content