Bug 78353 - I18N - can't input multibyte into class diagram attributes or operations names through edit control
I18N - can't input multibyte into class diagram attributes or operations name...
Status: NEW
Product: uml
Classification: Unclassified
Component: General Diagram
5.x
Sun All
: P2 with 1 vote (vote)
: 6.x
Assigned To: issues@uml
issues@uml
griffin_stopper, GRIFFIN_CANDIDATE
: I18N
: 97037 97041 (view as bug list)
Depends on: 77336
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-19 22:15 UTC by Ken Frank
Modified: 2008-06-27 18:42 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
info (1.80 KB, text/plain)
2006-06-19 22:16 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2006-06-19 22:15:47 UTC
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.
Comment 1 Ken Frank 2006-06-19 22:16:31 UTC
Created attachment 31177 [details]
info
Comment 2 Ken Frank 2006-08-29 03:01:08 UTC
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
Comment 3 Thuy.d Nguyen 2006-10-27 18:02:28 UTC
This is Tom Sawyer dialog and the issue has been fixed.
Comment 4 Ken Frank 2006-11-07 18:33:57 UTC
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
Comment 5 Ken Frank 2006-11-10 05:14:17 UTC
was fixed but reopened.
Comment 6 Thuy.d Nguyen 2006-12-06 23:49:25 UTC
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.
Comment 7 Yang Su 2007-02-14 22:57:43 UTC
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. 
Comment 8 Yang Su 2007-02-14 22:58:35 UTC
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. 
Comment 9 Yang Su 2007-02-14 23:04:07 UTC
already fixed
Comment 10 Trey Spiva 2007-02-14 23:15:07 UTC
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.
Comment 11 Ken Frank 2007-02-15 17:23:59 UTC
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
Comment 12 Ken Frank 2007-03-02 17:04:44 UTC
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
Comment 13 Ken Frank 2007-03-02 17:08:46 UTC
*** Issue 97037 has been marked as a duplicate of this issue. ***
Comment 14 Ken Frank 2007-03-02 17:10:08 UTC
*** Issue 97041 has been marked as a duplicate of this issue. ***
Comment 15 Ken Frank 2007-03-02 17:11:35 UTC
please see the details in 97037 and 97041 as to why this was reopened.

ken.frank@sun.com
Comment 16 Ashizawa Kazunori 2007-03-06 06:07:38 UTC
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.
Comment 17 Peter Lam 2007-03-06 06:55:27 UTC
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.
Comment 18 Will Zhang 2007-03-06 08:03:26 UTC
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.
Comment 19 Ashizawa Kazunori 2007-03-06 08:15:41 UTC
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.
Comment 20 Ashizawa Kazunori 2007-03-06 08:49:46 UTC
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)
Comment 21 Peter Lam 2007-03-07 23:39:11 UTC
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.
Comment 22 Viktor Lapitski 2007-03-08 04:11:48 UTC
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
Comment 23 Ashizawa Kazunori 2007-03-09 07:09:34 UTC
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" \^^/
Comment 24 Viktor Lapitski 2007-03-23 18:51:24 UTC
griffin i out, marking as RESOLVED
Comment 25 Viktor Lapitski 2007-03-23 18:52:31 UTC
in the comment before was a typo, i  meant "griffin IS out"
Comment 26 Ken Frank 2007-05-25 19:55:18 UTC
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
Comment 27 Ashizawa Kazunori 2007-05-28 03:21:46 UTC
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)
Comment 28 Ken Frank 2007-05-28 03:52:50 UTC
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
Comment 29 Ashizawa Kazunori 2007-05-28 05:36:28 UTC
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.
Comment 30 Ken Frank 2007-06-08 19:42:47 UTC
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
Comment 31 Ken Frank 2007-06-09 16:26:04 UTC
reopening as per Kasha's latest comments and after
confirming with Viktor that its appropriate to reopen.

ken.frank@sun.com
Comment 32 George Vasick 2007-09-21 19:26:39 UTC
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.
Comment 33 George Vasick 2008-01-02 16:53:55 UTC
Diagram area bugs waived for 6.0 will also be waived for 6.1.
Comment 34 Ken Frank 2008-04-14 22:36:44 UTC
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
Comment 35 Peter Lam 2008-05-23 21:45:42 UTC
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.
Comment 36 George Vasick 2008-06-06 00:39:30 UTC
I18N support is targeted for 6.5M2.
Comment 37 Trey Spiva 2008-06-26 22:48:43 UTC
From peters comments, does this mean that the issue is fixed?
Comment 38 Ken Frank 2008-06-26 23:25:55 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo