Community
Participate
Working Groups
Here is an example showing that computeSize is not returning a size big enough to fit the text. If SWT.DEFAULT is used it shows the text but if 450 is used instead of SWT.DEFAUT then part of the text is cut out. ** Run the example. All 5 lines show appear. import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.*; import org.eclipse.swt.events.*; import org.eclipse.swt.events.SelectionListener; import org.eclipse.swt.graphics.Point; public class Explorer { public static void main(String args[]) { String line2 = "aHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHb"; Display display = new Display(); Shell shell = new Shell(display); Label label = new Label(shell,SWT.WRAP | SWT.BORDER); label.setText("line 1\n" + line2 + "\nline3\n\nline5"); // Point size = label.computeSize(SWT.DEFAULT,SWT.DEFAULT); Point size = label.computeSize(450,SWT.DEFAULT); shell.setBounds(100,100,size.x + 20,size.y + 100); System.out.println("Shell " + shell.getBounds()); label.setBounds(10,10,size.x,size.y); System.out.println("Label " + label.getBounds()); shell.open(); System.out.println("Shell " + shell.getBounds()); System.out.println("Label " + label.getBounds()); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
*** Bug 10503 has been marked as a duplicate of this bug. ***
We have a case in the UI where the last line, which is cut out, is in a dialog and asks the user if he wants to exit the workbench.
If SWT.WRAP is not used it working fine. When it is used an extra \n is added before line3.
CM to investigate.
The Windows call (DrawText with DT_CALCRECT and DT_WORDBREAK flags) that we use to figure out the height truncates the extra-long 'word', and then incorrectly adds an extra blank line, which pushes the last line off of the bottom. If we add the DT_EDITCONTROL flag (i.e. "pretend to draw to a Text instead of a Label"), then computeSize gets the height right, and the last line shows correctly. Unfortunately, the extra-long word will always be truncated because this is the platform definition of what a Label does if non-breaking text is too long to display. The only suggestion I have is for the application to work around the truncation problem by calculating the width of the extra-long word using the label's font, and then either setting the label width to this (watch out for screen width), or inserting a '\n' or '...' at your preferred width. I am marking this bug fixed because the real problem (last line does not show) is now fixed.