4

Background: In a certain dialog there are several controls in a row. I would like all of them to have the same apparent height. However for a combobox with the CBS_DROPDOWNLIST style and no CBS_OWNERDRAW* I am having trouble changing the apparent height.

Question: How can I change the apparent height of such a DROPDOWNLIST combobox?

I am aware that the combobox does not allow changing the height with SetWindowPos. I was however under the impression that sending a CB_SETITEMHEIGHT message with wParam= -1 should modify the height. This method does work for comboboxes with the CBS_OWNERDRAWFIXED style set (I wanted to avoid setting this style though to preserve the "button-like" look).

Environment: My Win32 application uses Common-Controls 6.0 and I am concerned about the appearance in an environment where visual styles are enabled (Windows 7, Aero).

Daniel Flassig
  • 678
  • 4
  • 8
  • try [MoveWindow](http://msdn.microsoft.com/en-us/library/windows/desktop/ms633534(v=vs.85).aspx) – Edward Clements May 26 '13 at 09:28
  • No, just as SetWindowPos, MoveWindow does not affect the apparent height. As a workaround I switched to using split buttons with the split style BCSS_NOSPLIT and a popup menu. This way I loose the builtin automatic selection upon typing the item name - but the slightly degraded keyboard accessibility seems acceptable in my use case. I would still be interested in an answer to the question though. – Daniel Flassig May 28 '13 at 08:05

1 Answers1

3

I don't think this is possible.

As you mention, neither SetWindowPos nor MoveWindow work like you expect. That's because the height of a ComboBox includes the height of the drop-down. The control automatically resizes itself according to the size of the font it uses. So to change the size, change the size of the control's font by sending it a WM_SETFONT message.

But I don't understand why this is a problem. You say that you want a series of controls to have the same height, but unless you're changing the height of the other controls, they should already match. Since all controls on a dialog generally use the same font, combo boxes and text boxes should all have the same height already. When you use v6 of the common controls and Visual Styles are enabled, they'll be applied to all of these controls and they should have a uniform appearance. You shouldn't have to mess with the heights manually.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • The question arises especially for buttons next to comboboxes, as the buttons just size according to the parameters of CreateWindow (or the DLUs in the dialog resource for that matter). I haven't experimented with BCM_GETIDEALSIZE yet though. – Daniel Flassig May 30 '13 at 10:28
  • @DanielFlassig if you still haven't by now, BCM_GETIDEALSIZE is a tight fit size – andlabs Jan 22 '17 at 19:19
  • @CodyGray okay, I know this is resurrecting the dead, but I've seen a few people in the past 4 weeks or so say this about visual styles and it's left me utterly confused: does merely having a manifest and calling `InitCommonControlsEx()` automatically apply the correct fonts to controls, or not? Because in my experience it does not, but everyone else seems to think it does?... Again, sorry for the resurrection, but I'm really confused now :S (FWIW I found this answer looking for a way to get the height of an unthemed combobox collapsed for layout; GetComboBoxInfo() might be my only option) – andlabs Jan 22 '17 at 19:21
  • No, it does not, @andlabs. It never has. I don't know who is claiming that, but they are incorrect. For a control that you create (e.g. by calling CreateWindow), you have to manually set the font you want, otherwise you get the nasty 16-bit Windows SYSTEM font. For dialog boxes, you can set a combination of flags (I forget exactly what they are and am too lazy to look them up, something like DS_SYSFONT) and get a font automatically set, but this *still* isn't the correct font on Vista and later, since the default font changed to Segoe UI. See http://stackoverflow.com/a/6057761/366904 – Cody Gray - on strike Jan 23 '17 at 16:43
  • And yes, @andlabs, `GetComboBoxInfo()` is what I would use. At least, that would be my first instinct. Why are you second-guessing that choice? – Cody Gray - on strike Jan 23 '17 at 16:46
  • @CodyGray then I am probably misinterpreting what people were talking about. I forget the question right now, but it was recent. Also I'm not second-guessing myself so much as I am wondering if there was something else I was missing. It seems that `GetWindowRect(COMBOBOXINFO.hwndCombo)` is the key here; the two RECTs in that structure do not add up (when unthemed). – andlabs Jan 23 '17 at 19:10