Community
Participate
Working Groups
It would be worth investigating the feature gap between CCombo and regular Combo, and see whether: 1. there is none, so CCombo should be deprecated 2. there is some, but some CCombo feature could properly be ported to regular Combo, so we could plan a port of feature and then deprecate CCombo 3. There is a major one, and we should document it in Javadoc Currently, CCombo doc says """ * CCombo was written to work around certain limitations in the native * combo box. Specifically, on win32, the height of a CCombo can be set; * attempts to set the height of a Combo are ignored. CCombo can be used * anywhere that having the increased flexibility is more important than * getting native L&F, but the decision should not be taken lightly. * There is no is no strict requirement that CCombo look or behave * the same as the native combo box. """ Is this still true? Or did Combo receive the possiblity to set its height on all supported WS?
Created attachment 282276 [details] Screenshot I just stumbled over this as I was wondering why the height hint on a Combo did not have an effect. The desired height (29*scaling) was overruled by the computed height (24*scaling). (Display scaling was set to 200% in this case). The controls look rather different. I doubt they could be brought together. The place where this is overruled in Windows Combo is in org.eclipse.swt.widgets.Combo.computeSizeInPixels(int, int, boolean) if (((style & SWT.SIMPLE) == 0) && OS.GetComboBoxInfo (handle, pcbi)) { width += pcbi.itemLeft + (pcbi.buttonRight - pcbi.buttonLeft); height = (pcbi.buttonBottom - pcbi.buttonTop) + pcbi.buttonTop * 2; Maybe the height should be the Max(hHint,(pcbi.buttonBottom - pcbi.buttonTop) + pcbi.buttonTop * 2)? Anyway, the docs are still valid, and we are speaking of similar but different controls.
