Community
Participate
Working Groups
Steps: 1)Create simple file named foo.usr. 2)Open the propertysheet example editor on this file. 3)Select a department (or group or whatever) and go to edit the name of that object in the propertysheet 4) Shift+SPACE to enter canno input mode. 5) Type "nihongo" and press ENTER When you press ENTER, the propertysheet receives either a bogus widgetDefaultSelected event, or a bogus focusLost event. In either case, the entered canna text is lost. This affects anyone who displays a popup celleditor and is interested in the events mentioned above. This bug affects multiple GEF clients in WSAD
*** Bug 39018 has been marked as a duplicate of this bug. ***
How can I get this "propertysheet example editor" ? Is this part of Eclipse ?
Yes, it is part of the Eclipse Examples
I do not have access to GTK machine, otherwise I would provide the test snippet. Instead of downloading examples, why not start with a Shell and a Text Control, and add a focusLost and widgetDefaultSelected listener to the Text control. Neither event should be fired when the canna characters are committed.
Did anyone try another input server?
I don't think using a different conversion server would help, maybe other input method than kinput2 can behave differently. (note, I assuming that you guys are using kinput2). I'm not completely sure that the focus out and the selection events are bogus... maybe it is just what happens. When entering Japanese input the user can use space space to invoke the candidate conversion window. In this case the text widget actually lost the focus for the candidate window. Once the input is commit the focus returns to the widget what can be causing the selection event you refer. I know that in your step you don't talk about using the candidate window but I just saying the lost focus event might occur. I'll look at this problem.
widget *default* selected is different than just the caret being positioned (widget selected).
The problem is not with candidate window. The problem is TextCellEditor's behavior with Japaense input. You should try PropertiesView example or any TextCellEditor on workbench. The following code in TextCellEditor#createControl() may be a hint to fix this problem. ------------------------------------------------------- text.addKeyListener(new KeyAdapter() { // hook key pressed - see PR 14201 public void keyPressed(KeyEvent e) { ----> keyReleaseOccured(e); ------------------------------------------------------- I think defaultWidgetSelected() should be used instead of handling KeyPressed event for enter-key directly. So how about the following code ? ------------------------------------------------------- text.addSelectionListener(new SelectionListener() { public void widgetSelected(SelectionEvent e) {} public void widgetDefaultSelected(SelectionEvent e) { // same with enter-key handling code in keyReleaseOccured(e); fireApplyEditorValue(); deactivate(); } }); text.addKeyListener(new KeyAdapter() { // hook key pressed - see PR 14201 public void keyPressed(KeyEvent e) { //keyReleaseOccured(e); ------------------------------------------------------- ESC key handling also needed. Actually, key press event should not be sent to application if the key event is used by IM. But current implementation of GTK's Text widget seems not to do so. I have not looked into GTK, but currentlly, I think it is a problem of GTK2. The above code is a kind of workaround of it.
Yes, that is workaround. I think we all agree the meaning of ENTER was to commit the DBCS characters, therefore the text control should not receive the event. I'm suprised CellEditor was written this way. I wonder why widgetDefaultSelected was not used initially?
Randy, I did what you said: simple test with a Shell and a Text, I hooked Modify, FocusOut, Selection, DefaultSelection. I don't see the bogus events you are talking about. I noticed that the enter key is always filtered when in japanese mode (gtk filtered). But you still get DefaultSelection events. We have changed this part of the code a week ago, I advise you guys to use the latest SWT code for testing. I still didn't find the property sheet editor example...
Click on any eclipse downloads page and scroll down to "Example Plug-ins". As I mentioned before, you must create the file "xxx.usr", there is no wizard or any other indication that the propertysheet plugin exists. What is the bugzilla corresponding to the changed 2.1.1 code a week ago?
It works fine for me on HEAD. Test with GTK 2.2.1 and GTK 2.2.2, running on SuSE 8.2, locale ja_JP Which Linux and GTK version are you guys running ?
Actually, which version of eclipse are you guys running ? eclipse 2.1.1 or eclipse 2.1 >.
"What is the bugzilla corresponding to the changed 2.1.1 code a week ago?" what changed ? the one I mention on comment 11 (this one is related with filtering keys and was only released on HEAD) -or- the fix for bug 38388 (see the swt build notes)
We were using GTK 2.2.0, and 2.1.1 that might be as old as 2 weeks, but not older. Cam, can you have Hwa download the latest 2.1.1 Eclipse and find me on Friday to confirm?
It fails on 2.1.1 but works on HEAD cause of the changes for filtering key. The problem is that the application is receiving the Enter key before OS and try to get the text of the widget, but at this moment the text is still on the preedit buffer (it will only be committed to widget after the OS sees the Enter Key). It works when the DefaultSelection event is used (instead of testing for the Enter key during the KeyPress) because the DefaultSelection happens after the OS. This is the workaround for this problem.
Are you saying that defaultSelected is not fired, or just that it is fired after the OS widget receives the characters? The correct behavior is for defaultSelected *not* to fire. The user should be able to alternate between DBCS and normal entry without the CellEditor closing. If defaultSelected is being fired, the cell editor will be closed prematurely.
Randy, DefaultSelection is send when Enter is pressed on a SWT.SINGLE Text. you can verify this on Windows. If the app was using DefaultSelection to close the CellEditor it would work (see comment 8). When DefaultSelection happens the input process is over and the text is available in the widget. During the key press is indeed premature to close CellEditor.
Yes, I verified this today using GTK 2.2.0. There are no problems with default selection events. '\r' key event is the only problem. In situations when '\r' should *not* be reported, it is. When '\r' should be reported, and DBCS entry is still active but the candidate window is empty, the keyevent is sent twice instead of only once.
Randy since this problem was fixed in HEAD a couple weeks ago and it won't be released in 2.1.1 stream (it is too risky at this point) I'm closing this bug as won't fix.
You might suggest the workaround to Platform/UI, since listening to widgetDefaultSelected is probably both a safe change and more correct than the current code.
After re-reading all of the comments (comment #16), it seems that the current 3.0 state is that the OS receives the ENTER key, and *then* the Text control receives the enter key when the candidate window is committed. This is still incorrect behavior. The ENTER key should not be sent at any time. So, if I understand correctly, the user is now (in 3.0) able to insert DBCS characters, but once he has done so, the CellEditor applies the change and closes, making it really frustrating to add some kanna characters followed by some english characters.
Nick, the safest fix for enabling DBCS on GTK TextCellEditor seems to be changing the listener mechanism used to signal "apply". Should we split this bug into a 3.0 SWT fix, and a 2.1.x JFace workaround?
If hooking DefaultSelection instead of checking key events for CR is the right answer, then that's what we'll do. Felipe, please advise. Randy, if you could enter a UI PR, with a suggested patch, that would help.
If the Text widget has the style SWT.SINGLE you can use the event SWT.DefaultSelection to work around this problem.
Felipe, In fact, this "workaround" is probably more correct than the original technique of listening for '\r'. TextCellEditor has to be careful because createControl can be overridden, although it is extremely difficult to do this because you have to duplicate all of the hooking of listeners, and copy private methods.
The SWT team will look at this for 2.1.2
Felipe - can you change the milestone to 2.1.2
Fixed in HEAD (>20030903). I've tested Motif/Gtk/Windows and they all have the same behaviour. As said in comment#20, the fix in HEAD too much code and too risk to be back port to the R2_1_maintenance stream. Leaving this pr open until we decide what to for 2.1.2.
FH, are we sure that some other simpler hack cannot be used to fix this for 2.1.2?
closing pr.
As of 3.0 M6, TextCellEditor is no longer forwarding keyReleased events from the Text Control back to its protected (and overridable!) method: keyReleaseOccured(KeyEvent keyEvent). We are using a TextCellEditor with the MULTI style. It will *never* fire widgetDefaultSelected, therefore we are looking for CTRL+ENTER. I'm leaving this bug in SWT for now for consideration of firing widgetDefaultSelected when CTRL+ENTER is typed into a multi-line Text widget. If this change will not be made, route to JFace for them to resume sending us the keyReleaseOccured (KeyEvent keyEvent). BTW, they probably need to do this anyway.
There is no operating system standard says we should do this. Reassigning to JFace.
Made the following changes to TextCellEditor: - calls keyReleaseOccured (sic) as before - overrides keyReleaseOccured to: - pass on everything to super except for Enter (this is now handled by default selection) - handle Ctrl+Enter if the Text has SWT.MULTI style - handling of default selection factored into new method handleDefaultSelection Let me know if this works for you.
We have been asked to provide a patch to 2.1.x for this. Randy, can you confirm that the latest change to TextCellEditor (in HEAD, not in any integration build yet) addresses the problem on GTK, that it will also work on 2.1.x, and that no SWT changes are necessary? I'm reopening this until we get the patch in.
AFAIK, using widgetDefaultSelected is a perfect workaround. I would be cautious about the other changes which are in HEAD which are not related to this issue. For example, handling CTRL+ENTER (for MULTI line) and not passing that event through to subclasses extending keyReleaseOccured(..). I believe it was possible in 2.1.x to set celleditor styles. We are setting a new RHE machine and will test when it is ready.
Note that keyReleaseOccured is now called again, but is overridden in TextCellEditor to ignore '\r'. But I agree that the MULTI support should be taken out for a patch against 2.1.x.
I checked out the changes from Head and tested on M7 on GTK. The canna input mode works fine, no extra event was fired when the canidate selection window was used. Also, CTRL+ENTER is now resulting in the desired behavior of applying the editor value on the MUTLI TextEditor.
Patch released to the R2_1_maintenance stream, for the next R2.1.3 candidate build. This has the change to handle Enter via the default selection event rather than the key event, but does not include the support for multi-line text editors.
Fixed in 2.1.3 and 3.0 stream. This PR now represents the 2.1.3 work. If there are further problems with this in the 3.0 stream, please open a new PR.
verified on MOTIF on build 2.1.3RC2
Randy, can you please verify this using 2.1.3RC2 on GTK?
Verified on Win2000 using 2.1.3RC2.
Verified on GTK using 2.1.3RC2. However, found https://bugs.eclipse.org/bugs/show_bug.cgi?id=53876 while testing.
verified on mac, using property sheet example v20030312
