Bug 387333 - StyledText.computeSize fails with margins and indents
Summary: StyledText.computeSize fails with margins and indents
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.2   Edit
Hardware: Macintosh Mac OS X
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-15 19:59 EDT by Doug M CLA
Modified: 2020-02-24 12:09 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Doug M CLA 2012-08-15 19:59:43 EDT
The intention of StyledText.computeSize is that you can give it the desired text wrapping width and it comes back with width and height for the Control that would fit the text, the "preferred" size. This works when margins and indent are zero, but fails otherwise, intermittently returning a height that is too large.

In StyledText.computeSize, it appears the code first subtracts out the margins from the width hint and wraps the text to that smaller width. By the return, however, it has added the margins to the original width hint and returned that with the height derived as above. If you size the control thereby, it is intermittently too high, depending on how many extra lines were wrapped to the smaller width. It looks like the author was confused about whether the width hint refers to the text wrap width, or to the wrap width plus margins, and switched interpretations in the middle.

For SWT.SINGLE StyledText areas a similar problem occurs when there is an indent. If the control is sized to the preferred width returned it will be too narrow because the indent was not accounted for in the calculation.

Workaround for SWT.MULTI is to set margins to zero, computeSize, add margins back into the returned width.

For SWT.SINGLE, also add the indent to the returned width.
Comment 1 Doug M CLA 2012-08-16 13:55:09 EDT
Rather:
Workaround for SWT.MULTI is to save control's margins, set margins to zero, computeSize, add margins back into the returned width, restore control's margins, size the control. Doubles resource consumption, but gets the job done.
Comment 2 Tomas R. CLA 2012-09-26 16:15:46 EDT
This bug is the same as https://bugs.eclipse.org/bugs/show_bug.cgi?id=390412
Comment 3 Eclipse Genie CLA 2020-01-22 04:14:29 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 4 Doug M CLA 2020-02-24 12:09:25 EST
Dear Eclipse Genie,

Thank you for automatically closing the bug report that I filed in 2012, almost eight years ago, without ever fixing it. At this point, I have moved on to other interests. The desktop app I was working on in 2012 was a complete failure, due to the numerous bugs in SWT's text handling, many of which could not be worked around. The response of SWT's developers was glacial or entirely non-existent. 

I can truly say that choosing SWT over Swing for this project was the worst design decision I have ever made in my long career. I am sure that SWT is highly tuned to the limited needs of Eclipse, but as a UI for general apps it is unfit for purpose. This fact should be declared upfront to preclude any other naive developer from making a similar disastrous decision.

Thanks for listening, if anyone is.