| Date: | March 10, 2006 / year-entry #89 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060310-17/?p=31973 |
| Comments: | 21 |
| Summary: | 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,... |
Many people are surprised to discover that when you create a combo box (either in code via 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 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)
Comments are closed. |
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?
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!
er, use a smaller dialog font?
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.
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.
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.
<<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?
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!
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.
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.)
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" :)
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.
"er, use a smaller dialog font?"
Smaller then the default?
…*places shortcut to magnifyer on the desktop*
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.
I and others are bite by this feature years before. As beginners, we were confused and couldn’t figure out what was wrong.
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?
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.
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.
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.