Community
Participate
Working Groups
Point result = text.computeSize(10, SWT.DEFAULT). Notice that result.x != 10. The JavaDoc for Control.computeSize says: "The preferred size of a control is the size that it would best be displayed at. The width hint and height hint arguments allow the caller to ask a control questions such as "Given a particular width, how high does the control need to be to show all of the contents?" To indicate that the caller does not wish to constrain a particular dimension, the constant SWT.DEFAULT is passed for the hint." According to this, if a control is given a non-default width hint, it must return that as its preferred width (and similarly for height). Layout classes should be able to rely on this behavior.
There's no bug here. The result includes any trmming that is necessary to show 10 pixels worth of content. Note that this is different from computeSize () that is returned from layout which does not include the trim.
If I understand this correctly, the arguments to computeSize are intended to be the inner content size rather than the control size. If this is true, then there are actually many bugs here, not just one. 1. Most Eclipse code that invokes computeSize(...) on a control with a non-default hint are passing in the control's outer size, not the content size. For example, it is common practise to use the result of computeSize as the width or height hint for a subsequent call to computeSize, and the client area of a parent composite is often used as the width hint for a child control intended to span the composite in some direction -- presumably these are invalid without adjusting for trim. Some code references: org.eclipse.jdt.internal.ui.text.link.contentassist.CompletionProposalPopup2.resizeProposalSelector org.eclipse.ui.internal.WorkbenchWindow.WorkbenchWindowLayout.layout(Composite, boolean) org.eclipse.jface.action.StatusLine.StatusLineLayout.layout(Composite, boolean) My brief search within Eclipse has not revealed any examples where a hint was intended to be the content size. 2. The standard (and very widespread) workaround for handling wrapping controls in GridLayout (see bug 9866) also makes this assumption (notice that the workaround subtracts the margin width for the parent layout from the width hint -- not the trim for the child control). 3. This means that there seems to be a defect in SWT: there is no way to determine the preferred height of a control given its outer width. This is necessary in order to write a layout that handles wrapping text correctly. Such a layout would know the width available to draw the wrapping control and would need to defer to the control to compute its height. To fix this, SWT would need to add a getTrim(int actualControlWidthOrSwtDefault, int actualControlHeightOrSwtDefault) method to Control. Note that Control.getBorderWidth() is not sufficient to compensate for trim -- some controls (like Text) can have different trim for each dimension, can have trim that is different from the border width, and there is no guarantee that the trim added in computeSize remains invariant under different size hints. 4. The JavaDoc for computeSize is not clear that the width or height hints refer to content size rather than control size, and the common usage seems to indicate that developers are interpreting it to refer to the control size. All of the above would be fixed by modifying the various SWT computeSize(...) methods to take the outer size as arguments rather than the content size. This would be a simplifying change within SWT. Given issues 1 and 4, this is likely to fix more code than it breaks (if any). Reopening as an enhancement: - Please either change the implementation of computeSize to take the control size as hints (rather than content size), or provide some other means to compute one dimension of a control's size, given another dimension which is known.
*** This bug has been marked as a duplicate of 46112 ***
