Community
Participate
Working Groups
4.4 M6, but also in older releases. When calling Shell#setText with a string that contains newlines (\n), the title moves up the more newlines there are until it becomes unreadable. import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class ShellTitleBug { public static void main(String[] args) { final Display display= new Display(); Shell shell= new Shell(display); shell.setText("This\nBug\nis\nugly"); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Created attachment 242528 [details] Works in my setup Seems to depend on OS settings, since this works for me: The lines are just concatenated, which is one of two good solutions. The other would be to just cut at the first \n, like TreeItem#setText(..).
This issue is not seen on Windows7, but can be seen on Linux Ubuntu. Proposed Solution: To address this issue, we will keep Windows7 behavior as reference & fix the Shell.setText() behavior on Linux.
(In reply to Niraj Modi from comment #2) > This issue is not seen on Windows7, but can be seen on Linux Ubuntu. Yes, it is seen on Windows 7, that's where I saw it and filed the bug.
On Windows7, I am not able to figure out which OS level setting is causing the shell title to split on new line character. Tried with few of the OS themes as well, but all worked for me. Anyways, if we attempt to fix this problem on SWT end by removing the \ n & \r in Shell.setText() method then we would need to keep track of original string to be returned via Shell.getText() method. For now we can update the current JavaDoc for Shell.setText() method stating that, if newline char is used in Shell title, the behavior is platform dependent.
Note that multi-line handling is inconsistent in many #setText(String) methods across different widgets and platforms. The problem could be mentioned in Javadocs, but we do that, then we should not only do it for Shell#setText(String). package snip; import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class ShellTitleBug { private static final String MULTILINE = "This\nBug\nis\nugly"; public static void main(String[] args) { final Display display= new Display(); Shell shell= new Shell(display); shell.setText(MULTILINE); shell.setLayout(new GridLayout()); new Label(shell, SWT.NONE).setText(MULTILINE); new Text(shell, SWT.SINGLE | SWT.BORDER).setText(MULTILINE); new Group(shell, SWT.NONE).setText(MULTILINE); Tree tree = new Tree(shell, SWT.BORDER); TreeItem treeItem = new TreeItem(tree, SWT.NONE); treeItem.setText(MULTILINE); new TreeItem(treeItem, SWT.NONE).setText(MULTILINE); treeItem.setExpanded(true); Table table= new Table(shell, SWT.BORDER); new TableItem(table, SWT.NONE).setText(MULTILINE); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
(In reply to Markus Keller from comment #5) > Note that multi-line handling is inconsistent in many #setText(String) > methods across different widgets and platforms. > > The problem could be mentioned in Javadocs, but we do that, then we should > not only do it for Shell#setText(String). Added a generic JavaDoc note w.r.t. to usage/behavior of escape characters like '\n', '\t' etc.. in below widgets for #setText() and List,ComboList#add() methods: - Button - Combo - Decorations(parent of Shell) - Group - Label - List - TableItem - Text - TreeItem Updated Windows files only(assuming changes will be copied over to other platform files via JavaDoc-Basher tool) via below git commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=eef9aae31d613bddb04ee66908f2982f5fa891a0
Updated few more classes including custom widgets for the JavaDoc note w.r.t. to usage/behavior of escape characters in #setText() method: - CCombo - CLabel - Item - ToolBar Refer git commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2421fb3ae62d819c660c8a65ad2613d75ea756c6 Resolving this bug now.
These java doc doc changes are not available on build I20150513-2000 on Linux. I tested by importing the swt source. These java doc changes are not available on in the linux source package
(In reply to Sravan Kumar Lakkimsetti from comment #8) > These java doc doc changes are not available on build I20150513-2000 on > Linux. I tested by importing the swt source. These java doc changes are not > available on in the linux source package Hi Sravan, Today only I made these JavaDoc change to win32 source.. These changes would be copied over to other platform files only when JavaDoc-Basher tool is run, which is yet to be done for Mars.
I guess I am too early for the test. Actually I am looking for CLabel and CCombo javadocs. These are common across all platforms
Updated JavaDoc for CCombo#add() methods too, via below git commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e3cc9c35f8a2e43dc795766aca1e50b8d3e0b65b
These characters are not called escape characters. They are control characters.
(In reply to Markus Keller from comment #12) > These characters are not called escape characters. They are control > characters. Hi Markus, Not sure if these two terms are synonyms, but Oracle docs usually refer these characters as Escape sequences: Spec: https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.6 Tutorials: https://docs.oracle.com/javase/tutorial/java/data/characters.html Stackoverflow: http://stackoverflow.com/questions/1367322/what-are-all-the-escape-characters-in-java
In general programming terms, escape/control characters/sequences are usually used interchangeably.. all referring to some non-graphics, non-printing character set. Java precisely refer these as "escape sequences", updated my JavaDocs accordingly: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d6e9a5cd1a69c0f96157482d1b5fd29f162cf11d
(In reply to Niraj Modi from comment #14) > In general programming terms, escape/control characters/sequences are > usually used interchangeably.. all referring to some non-graphics, > non-printing character set. Definitely not. And that some people constantly mix up terms is not a justification for us to continue the confusion. These APIs are not about the Java language, but about String objects that are passed by a client. References to the JLS are out of context. The String objects can just as well be constructed by other means (read from a file, compiled in a non-Java language, etc.) Most escape sequences in a String literal are handled perfectly well and are not platform-dependent. E.g. these are all fine: \"\'\\\u2603 The characters that are problematic are the control characters.
(In reply to Markus Keller from comment #15) > (In reply to Niraj Modi from comment #14) > > In general programming terms, escape/control characters/sequences are > > usually used interchangeably.. all referring to some non-graphics, > > non-printing character set. > > Definitely not. And that some people constantly mix up terms is not a > justification for us to continue the confusion. > > These APIs are not about the Java language, but about String objects that > are passed by a client. References to the JLS are out of context. The String > objects can just as well be constructed by other means (read from a file, > compiled in a non-Java language, etc.) Most escape sequences in a String > literal are handled perfectly well and are not platform-dependent. E.g. > these are all fine: \"\'\\\u2603 > > The characters that are problematic are the control characters. You didn't reverted on comment 13, so I assumed you were OK with JLS terminology. Anyways, Thanks for this explanation on control characters, I have updated my JavaDocs accordingly: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=20db836c37f4f983653ccdf81fb29ed3aa1c1494
