Community
Participate
Working Groups
I observed this with Text and Combo: - given a Composite with Gridlayout (one column, ClientArea-width 500) - create a Text and a Combo with the composite above as parent - both controls use GridData with a widthHint of 300 => after layout the text has a width of 323 and the combo 302. It turned out that the text control adds css border, left- and right-padding values to the calculated width, while combo only adds the css border values. This makes it impossible to layout both controls independently from the mentioned css settings in such a way that they appear with the same width. On a first glance I would expect that if the hint parameters of computeSize are not SWT.DEFAULT, border and padding should not be added. But I am somewhat indecisive on that, as with theming there are always a lot of things to consider. However I think the behavior should be consistently implemented by all controls.
Hi Frank, just did a small test under SWT (Windows): ... shell.setLayout( new GridLayout( 1, false ) ); Combo combo = new Combo( shell, SWT.NONE ); combo.setItems( new String[] { "item" } ); combo.setLayoutData( new GridData( 200, SWT.DEFAULT ) ); Text text = new Text( shell, SWT.NONE ); text.setText( "item" ); text.setLayoutData( new GridData( 200, SWT.DEFAULT ) ); shell.layout(); System.out.println( combo.computeSize( 200, SWT.DEFAULT ) ); // Point {227, 23} System.out.println( text.computeSize( 200, SWT.DEFAULT ) ); // Point {206, 15} System.out.println( combo.getSize() ); // Point {227, 23} System.out.println( text.getSize() ); // Point {206, 15} ... As you can see from the example above, providing the same widthHint for Combo and Text produces different widths in SWT (Windows) too. Do I miss something?
(In reply to comment #1) > As you can see from the example above, providing the same widthHint for > Combo and Text produces different widths in SWT (Windows) too. Do I miss > something? Good idea comparing the behavior with SWT and interesting results, too. So I was right with my doubts about my intuition. But anyhow this example still misses the point of different interpretation of the css padding settings. There is no such thing available in SWT and therefore I would expect the combo and the text to handle that matter identically. Setting the text padding to 0 0 0 0 renders the text with a size of 300 + border. Setting the combo (Combo-Field) padding to 0 10px 0 10px will be ignored in case a width hint is used for preferred size calculation (I would expect 320 + border). I was not sure whether this is intended or not, so I was discussing the issue with Tim this afternoon. He also found this somewhat fishy and asked me to file this bug. Actually he told me somewhat later that he ran into a similar problem shortly after our discussion. Currently I found a workaround for our use case (ok, not a nice one...) so it is not a pressing problem for us. But I am curious about the outcome... :-)
The padding applied on the Text is a "composite" padding (padding around the complete widget). That's why this padding is handled by computeTrim. In the Combo case there is no such a padding, but sub-widget (text field) padding, which is handled manually in Combo#computeSize. The padding in Text is considered as trimming, the padding in Combo-Field is not.
