Community
Participate
Working Groups
Build Identifier: M20090211-1700 The problem was found in Lotus Sametime 8.5.1 Connect Client witch uses StyledText in chat window for end-users to input instant messages. If entering Chinese characters with some Chinese Traditional input method, such as Chinese (Traditional) - Phonetic, end-users may happen to input nothing, and exceptions are shown in the console. The problem could be reproduced with a simple SWT application if referencing SWT 3.4.2 or 3.5.2, but not reproduced if referencing SWT 3.3.0. Code Snippets: public class TestStyledText { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("Problem of StyledText"); shell.setLayout(new FillLayout()); StyledText text =new StyledText(shell, SWT.BORDER); shell.setSize(300, 200); shell.layout(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); } } According to our investigation, the problem is caused by some changes in StyledText, which adds some COMPOSITION listeners to its IME object. And a workaround is to reset a new IME to StyledText, so that no COMPOSITION listener added to the new IME object. For example: StyledText text =new StyledText(shell, SWT.BORDER); text.setIME(new IME(text, SWT.NONE)); However, we need SWT development help to confirm if there is any impact? Why did SWT do those changes in StyledText. Could it be fixed by SWT, or is there a safer workaround? Reproducible: Always Steps to Reproduce: 1. Add IME for Chinese Traditional 1) Open Control Panel and double click Regional Options 2) Click on the Languages tab 3) Click on the Details button 4) Click on Add 5) Select Language Chinese (Taiwan) 6) Select Keyboard layout/IME: Chinese (Traditional) - DaYi 7) Click OK More details please refer to: http://seba.studentenweb.org/thesis/howto-winxp.php 2. Run TestStyledText 3. Switch IME to Chinese (Traditional) - DaYi 4. Press 'W' twice, showing 2 Chinese characters in underline style 5. Press Enter at this point 6. The application will crash, and show following exception in the console: Exception in thread "main" java.lang.IllegalArgumentException: Index out of bounds at org.eclipse.swt.SWT.error(SWT.java:3761) at org.eclipse.swt.SWT.error(SWT.java:3695) at org.eclipse.swt.SWT.error(SWT.java:3666) at org.eclipse.swt.graphics.TextLayout.getStyle(TextLayout.java:2087) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:864) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:656) at org.eclipse.swt.custom.StyledTextRenderer.calculate(StyledTextRenderer.java:201) at org.eclipse.swt.custom.StyledTextRenderer.calculateClientArea(StyledTextRenderer.java:219) at org.eclipse.swt.custom.StyledText.resetCache(StyledText.java:6454) at org.eclipse.swt.custom.StyledText.handleTextChanged(StyledText.java:5401) at org.eclipse.swt.custom.StyledText$6.textChanged(StyledText.java:4853) at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:67) at org.eclipse.swt.custom.DefaultContent.sendTextEvent(DefaultContent.java:795) at org.eclipse.swt.custom.DefaultContent.replaceTextRange(DefaultContent.java:788) at org.eclipse.swt.custom.StyledText.modifyContent(StyledText.java:5876) at org.eclipse.swt.custom.StyledText.sendKeyEvent(StyledText.java:6631) at org.eclipse.swt.custom.StyledText.doContent(StyledText.java:2186) at org.eclipse.swt.custom.StyledText.handleKey(StyledText.java:5145) at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5170) at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:4873) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1027) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1012) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1040) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1036) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1352) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3894) at org.eclipse.swt.widgets.Canvas.WM_CHAR(Canvas.java:341) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3787) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:337) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4528) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2274) at org.eclipse.swt.internal.BidiUtil.windowProc(BidiUtil.java:657) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2371) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3420) at TestStyledText.main(TestStyledText.java:26)
The new code implements in-line ime composition for StyledText (which also fixed a bunch of bugs in Korea IME). I can reproduce your problem on my machine, it seems that this IME in particular does not like in-line mode (using notepad/write it used over-the-spot). Maybe it is possible to detect this preference and use over the spot for Chinese (Traditional) - DaYi IME.
I was trying to detect this case using ImmGetProperty() and disabling in line composition (IME#isInlineEnabled()) when IME_PROP_SPECIAL_UI is set, but that didn't work (the bit is never set). The one difference I saw was that all IMEs I tested (japanese, korean, chinese PRC) set the IME_PROP_AT_CARET flag, the only IME that did not set the flag was Chinese (Traditional) - DaYi IME. Maybe we can use this flag to disable inline compositin for DaYi IME.
Thanks, Felipe! The problem could be reproduced with following input methods: Chinese (Traditional) - ChangJie Chinese (Traditional) - Phonetic Chinese (Traditional) - Big5 Code Chinese (Traditional) - Unicode Chinese (Traditional) - Array Chinese (Traditional) - Quick Could you check if they set the IME_PROP_AT_CARET flag? Maybe I have to provide a workaround for our customer based on current SWT implementation. I plan to introduce an Eclipse preference to disable/enable in-line mode for our StyledText, so it could be controled by end-users.
(In reply to comment #3) > Maybe I have to provide a workaround for our customer based on current SWT > implementation. You will need a modified version of SWT including a patch for this problem. > I plan to introduce an Eclipse preference to disable/enable in-line mode for > our StyledText, so it could be controled by end-users. Maybe we can add a -Dswt.ime.mode=default|inline variable. Silenio ?
will it be possible to get a patch for SWT 3.6.2 ?
We first need to fix this HEAD. Silenio, let me know when you have time to take a look at this problem. mukundan desikan: Do you need a fix for the problem described in the first comment, or do you really need an API to disable in-line IME ? Note, if you only the fix for the bug, then the solution in comment 2 is good (needs testing on all the IMEs you listed on comment 3).
Will check with the author and let u know as soon as possible. Thanks !
I have tried another way to disable in-line IME: StyledText text =new StyledText(shell, SWT.BORDER); text.setIME(new IME(text, SWT.NONE)); Set a new IME object which is not in-line because no COMPOSITION listeners added to this object. I add an Eclipse preference to control whether or not to disable in-line IME. The problem is we need customer to determine if they need set the preference according to their frequently used IME. So it would be better if SWT can handle it in StyledText code: detect current IME is one of the IMEs listed in comment 3 and disable in-line automatically.
Windows 7 does not have this problem, on Windows 7 all the IMEs have IME_PROP_AT_CARET set to true and inline composition looks fine.
Created attachment 198837 [details] [work in progress] patch
Same exception was reported for SWT 4.3.1 for our SmartGit.
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.
