You need to log in before you can comment on or make changes to this bug.
This is on windows or unix. This is similar for all diagrams. Run in zh locale and create class diagram with class in drawing area You can select class name in diagram and input multibyte to change it But not for names of attributes or operations. You can however paste the multibyte into the attribute or operation name to change it. Likewise, if create new operation or attribute in java code editor, with multibyte as part of the name, it does show correctly in diagram. this actually is about any part of diagram element on design pane using editor control to add/change/delete diagram names, attributes, operations or whatever else might be valid for that kind of element - see 5th comment note for details as of 10/04/05 attached is some additional information/description about what was observed in Japan.
Created an attachment (id=31177) [details] info
This seems like a very important kind of functionality - to be able to use these areas of diagram to add or change names of or attributes or operations - a basic functionality - that is, if this happened in english locale, wouldn't it be fixed for entpack for sure ? if so, why not for users who input multibyte ? ken.frank@sun.com
This is Tom Sawyer dialog and the issue has been fixed.
Reopening - this does not appear to have been fixed, at least on windows. I tried in using Japanese and someone who knows Chinese tried it in zh locale. on solaris I can do simple input of Japanese however but will need to have more complex input done on that also to see if works in all use cases, since there are various but common input modes and techniques for ja and zh locales. ken.frank@sun.com
was fixed but reopened.
This issue has not been fixed and is not at all related to Tom Sawyer dialog . My comment on Oct 27, "This is Tom Sawyer dialog and the issue has been fixed.", must be the comment for a TS related issue but I mistakenly put it on this issue without knowing it. Will look at this issue in griffin.
I tested the latest build on Windows, this is no longer an issue. I believe Victor's fix to issue 77336 fixed this one as well.
already fixed
Now, I have to admit that I am new to the testing I18N, but I was not able to reproduce this issue. I am on a Mac, and I used the international settings to change my language to Chinese. I then used the software keyboard to enter text. I was able to create attributes and operations. I was also able to use the software keyboard to type in chinese characters. I used the setting to use double byte romain characters. Again, since I am new to this kind of testing, I may have done something incorrectly.
will verify this now and try to get the edit control areas exercised more using more complex and usual input of multibyte characters to better emulate real usage. ken.frank@sun.com
More detailed usage of typical input of multibyte characters has shown this is not really fixed; will refer to several recently filed bugs here that were closed as duplicates; they are about this same issue. (97037, 97041) Since the input of multibyte is more complex than the input of ascii, that is why in this bug (and in older ones now closed) that it might seem as if its separate situations, but it does not appear to be. Let's make sure to keep this issue as the one that represents the situation of multibyte input in drawing area for asian locales, so uml team has just one issue to refer to. ken.frank@sun.com ken.frank@sun.com
*** Issue 97037 has been marked as a duplicate of this issue. ***
*** Issue 97041 has been marked as a duplicate of this issue. ***
please see the details in 97037 and 97041 as to why this was reopened. ken.frank@sun.com
97037 is reproducible in Coco. 97041 is also reproducible with slightly different symptoms. 1. start the IDE and open a UML project with Activity Diagram (or other diagram). 2. drop Invocation element (or other element) in diagram editor. 3. double click the element. 4. type Control-Space to activate input method 5. type "koredehadamedesu", then you will see "これではだめです" with underlined. 6. type Space, then you will see that "これでは" is reversed and "だめです" is underlined. 7. type Control-N to commit the first syllable. Now, "これでは" is not reversed, this is good. "だめです" disappears, which is bad. "だめです" should remain and be underlined here. 8. type Control-Space to deactivate input method.
I have done quite a bit of testing on this bug today in 2 locales: Japanese and Simplified Chinese. Everything seems to be working properly in the the Simplified Chinese environment. However, I found the following not working properly in the ja environment: 1. appending ja characters to existing English (en) string replaces existing en string with ja chars in both attributes & operations & element names 2. inserting ja chars in the front or middle of en string would move the ja chars 2 or 3 char positions to the right of cursor position The same experiment seemed to be working properly on both aforementioned locales using JSE 8.1.
NB 55 ml FCS + Griffin ml 070304 OS: Mac OS 10.4.5(Intel) Locale: zh Sanity testing on Mac OS: Append zh characters to element name, operation name and attribute name. Add zh chars at the head of en, insert zh chars into en, add zh chars at the end of en, replace en with zh chars The error result seemed un-regularly, main issue is: a. zh chars move to the right of cursor position b. zh chars disappear after finishing the ml input, only en is left Sometimes, it is successful, but the rate is low, so the situation is worse than other OS.
The other test case: OS: Solaris 10 / Solaris snv_59 Locale: ja / ja_JP.UTF-8 Java: 1.5.0_01 / 1.6.0 build: 070303 1. start the IDE and open a UML project with Class Diagram (or other diagram). 2. drop Node element (or any other element) in diagram editor. 3. double click the element, type Backspace to erase "Unnamed". 4. type Control-Space to activate input method (toggle). 5. type "a", then "あ" appears in reverse video. 6. type Return to commit the letter "あ", but "あ" remains reverse video. Reverse video should be cleared. 7. type Return again, then "あ" disappears and "Unnamed" reappears.
Log for the above test case... *********** Exception occurred ************ at 5:46 PM on Mar 6, 2007 java.lang.IllegalArgumentException: bad position: -1 at javax.swing.text.JTextComponent.setCaretPosition(JTextComponent.java:1650) at org.netbeans.modules.uml.ui.controls.editcontrol.EditControlImpl.setCurrentPosition(EditControlImpl.java:1564) at org.netbeans.modules.uml.ui.controls.editcontrol.EditControlImpl.inputMethodTextChanged(EditControlImpl.java:2281) at java.awt.Component.processInputMethodEvent(Component.java:6166) at javax.swing.text.JTextComponent.processInputMethodEvent(JTextComponent.java:4470) at java.awt.Component.processEvent(Component.java:5820) at java.awt.Container.processEvent(Container.java:2058) at java.awt.Component.dispatchEventImpl(Component.java:4410) at java.awt.Container.dispatchEventImpl(Container.java:2116) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Workaround: Use the Properties Editor to input multibyte characters for attribute/operation names, as well as element name instead of using the edit control from the element. The issue seems to be specific to the ja Hiragana character set. Seems to work properly in the simplified chinese locale environment in my experiment.
Fixed in trunk. Will change to "RESOLVED" once griffin is out. Hope "koredeha-usable-desu" :) Checking in uml/core/src/org/netbeans/modules/uml/ui/controls/editcontrol/EditControlImpl.java; /cvs/uml/core/src/org/netbeans/modules/uml/ui/controls/editcontrol/EditControlImpl.java,v <-- EditControlImpl.java new revision: 1.3; previous revision: 1.2 done Checking in uml/core/src/org/netbeans/modules/uml/ui/swing/drawingarea/ADDrawingAreaControl.java; /cvs/uml/core/src/org/netbeans/modules/uml/ui/swing/drawingarea/ADDrawingAreaControl.java,v <-- ADDrawingAreaControl.java new revision: 1.4; previous revision: 1.3
Tried on OS: Solaris snv_59 Locale: ja_JP.UTF-8 Java: 1.6.0 NetBeans: 6.0-m6 build: hydra 070308_9 I could not reproduce the problems. "koredeha-usable-desu" \^^/
griffin i out, marking as RESOLVED
in the comment before was a typo, i meant "griffin IS out"
Kasha and Will, since this was a long and complex issue, I wanted to confirm one more time that its now ok for you, before I place in verified state ? Thanks. ken.frank@sun.com
On NetBeans 6.0 m9, I found the other test case which fails. OS: Solaris snv_65 Locale: ja_JP.UTF-8 Java: 1.6.0 build: M9, 070502 1. start the IDE and open a UML project with Activity Diagram (or other diagram). 2. drop Invocation element (or other element) in diagram editor. 3. right click once (the Invocation element is still selected). 4. type Control-Space to activate input method 5. type "koredehadamedesu", then you will see "これではだめです" with underlined, in a separate window at the botom of IDE. problem-1: the contents of the separate window (called preedit strings) should appear on the target element. 6. type Space, then you will see that "これでは" is reversed and "だめです" is underlined. 7. type Control-N to commit the first syllable. Now, the whole strings (これではだめです) are put in the target element, as committed. problem-2: the second syllable should not be committed, and should remain as preedit. (if that the second syllable is not committed, typing Space brings up Lookup Choice window.) (I suspect that fixing problem-1 also fix problem-2)
Kasha, Thanks for providing this information. Please tell me if this might be accurate summary of the problem for uml diagrams and input of multibyte: It sounds like, for some typical kind of input of multibyte, things are ok in diagram items, like class, and for class name and attributes and operations ? But for other kinds of typical kind of input, things are not ok, regardless of which diagram type and which item from the pallette of that diagram type ? If so, then am wondering if uml can switch to using a drawing area that interfaces more directly with the java api/code that handle input methods; I think all other parts of netbeans don't have this problem since I think they don''t use a special library. I'd like to reopen this issue since it means certain typical input of multibyte cannot be done in uml diagrams, and all typical kind of multibyte input should be handled, IMO. ken.frank@sun.com
Hi Ken, > It sounds like, for some typical kind of input of multibyte, > things are ok in diagram items, like class, and for class name > and attributes and operations ? Correct. > But for other kinds of typical kind of input, things are not > ok, regardless of which diagram type and which item from the > pallette of that diagram type ? Correct. The operational difference between the former test case and this new test case is: former case - explicitly specify a target text field. new case - not explicitly specify a target text field. Just select a target element.
Viktor, I think this might need to be reopened based on Kasha's comments of Additional comments from kasha Mon May 28 02:21:46 +0000 2007 can you look at them and see if the steps are valid user action, no matter what the locale ? If so, I can reopen it. ken.frank@sun.com
reopening as per Kasha's latest comments and after confirming with Viktor that its appropriate to reopen. ken.frank@sun.com
Most cases have already been fixed. The full fix has a high chance of introducing regressions. We would rather wait until the next release. Work around is to click on the compartment and bring up the edit control before typing.
Diagram area bugs waived for 6.0 will also be waived for 6.1.
will new drawing and other new functionality/features of uml have changes or fixes on how multibyte is input, so that this issue on existing uml might not be valid ? please provide some details if so; otherwise its seems this and related issues should be fixed and not waived anymore ? ken.frank@sun.com
In zh_CN locale using NB 6.5 build, I'm able to copy the multibyte chinese characters "阿爹" (hope it shows up) and pasted it to both the attribute and operation name. This is on Windows Vista.
I18N support is targeted for 6.5M2.
From peters comments, does this mean that the issue is fixed?
Peter's most recent comment in issue is about copy/paste, but this issue is about input of multibyte into the area using the usual input tools provided with an OS for Japanese or Chinese. development team , please confirm via unit testing first that it works ok now, then resolve it if so, then it will undergo verification as usual. ken.frank@sun.com
